Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiletest: Run revisions as independent tests. #50400

Merged
merged 4 commits into from
May 17, 2018

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented May 2, 2018

Fixes #47604.

  • The output of each test is now in its own directory.
  • "auxiliary" output is now under the respective test directory.
  • stage_id removed from filenames, and instead placed in the stamp file as a hash. This helps keep path lengths down for Windows.

In brief, the new layout looks like this:

<build_base>/<relative_dir>/<testname>.<revision>.<mode>/
    stamp
    <testname>.err
    <testname>.out
    a (binary)
    auxiliary/lib<auxname>.dylib
    auxiliary/<auxname>/<auxname>.err
    auxiliary/<auxname>/<auxname>.out

(revision and mode are optional)

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 2, 2018
@ehuss
Copy link
Contributor Author

ehuss commented May 2, 2018

Note: It might be easier to review if you look at the diff for the commit after the rustfmt commit.

Concerns:

  • Are there any tools (besides update-references) that depend on the directory layout of the test output?
  • How do I enable wasm32-unknown-unknown? How do I run the tests in test/run-make?
  • Why was canonicalize() used in stamp()? Why was it not used elsewhere?
  • Should the hasher be changed? I noticed Cargo uses SipHasher24, but that is deprecated?
  • I wanted to remove the duplicate logic for paths, but it all ended up in common.rs. I'd like to move it all into TestCx, but that would require TestCx being created earlier for the "stamp" check. This patch was already getting a little big, so I held off. That could be more elegant.
  • Changing the binary name to a might be surprising? An alternative is to rename some of the very long test names. Here is an example of a very long path that causes problems if you use the full test name: d:\Proj\rust\rust\build\x86_64-pc-windows-msvc\test\ui\nll\closure-requirements\region-lbr1-does-outlive-lbr2-because-implied-bound\region-lbr1-does-outlive-lbr2-because-implied-bound.region_lbr1_does_outlive_lbr2_because_implied_bound0-317d481089b8c8fe83113de504472633.rs.rcgu.o

@bors
Copy link
Contributor

bors commented May 4, 2018

☔ The latest upstream changes (presumably #49870) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented May 5, 2018

☔ The latest upstream changes (presumably #50084) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented May 7, 2018

☔ The latest upstream changes (presumably #50000) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really nice! It feels like the path handling is much cleaner than before, even if it's still a bit messy.

fn output_base_name(&self) -> PathBuf {
let dir = self.config.build_base.join(&self.testpaths.relative_dir);
/// The revision, ignored for Incremental since it wants all revisions in
/// the same directory.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All these special cases definitely make me think that separating out the incremental phases from revisions would be a good idea -- but maybe in a follow-up PR.

@nikomatsakis
Copy link
Contributor

@ehuss

Are there any tools (besides update-references) that depend on the directory layout of the test output?

Don't think so. @alexcrichton couldn't think of any either. Maybe someone from @rust-lang/infra has thoughts though.

How do I enable wasm32-unknown-unknown? How do I run the tests in test/run-make?

I don't really know about this.

Why was canonicalize() used in stamp()? Why was it not used elsewhere?

I don't know this either. There may not be a reason? Maybe check the git blame and see who put those stamps in...

Should the hasher be changed? I noticed Cargo uses SipHasher24, but that is deprecated?

What is hasher used for exactly?

I wanted to remove the duplicate logic for paths, but it all ended up in common.rs. I'd like to move it all into TestCx, but that would require TestCx being created earlier for the "stamp" check. This patch was already getting a little big, so I held off. That could be more elegant.

OK -- how it is still seems more centralized than before. I like the "one directory per test" etc.

Changing the binary name to a might be surprising?

Maybe, but I don't think it matters.

@nikomatsakis
Copy link
Contributor

I'd be happy to land this as is -- does anyone from @rust-lang/infra want to take a look too?

@ehuss
Copy link
Contributor Author

ehuss commented May 9, 2018

Maybe check the git blame and see who put those stamps in...

It was @alexcrichton in #39431 (c8e0d04).

Hmm, just noticed #40578 which changed the stamp name for ecryptfs which says it has a 145 character limit. We're way over that now, so maybe that isn't something that can be realistically handled now?

What is hasher used for exactly?

Right now it just hashes the stage ID (instead of placing it in a filename). If you run tests for a different stage, it will invalidate the cached results and re-run the tests. It can be used to fingerprint anything else we want in the future.

@alexcrichton
Copy link
Member

Oh as long as we're within limits on Windows I think we're good, and it looks like this is already taking that into account and optimizing for it!

@nikomatsakis
Copy link
Contributor

@bors r+ -- let's do this!

@bors
Copy link
Contributor

bors commented May 10, 2018

📌 Commit e0a6acd has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 10, 2018
@ehuss
Copy link
Contributor Author

ehuss commented May 10, 2018

@nikomatsakis Just a warning, this conflicts with #50447. If this can get through the queue in a reasonable amount of time, I suggest just closing #50447.

@kennytm
Copy link
Member

kennytm commented May 10, 2018

#50447 has been rolled up into #50608, so it will be merged first.

@ehuss
Copy link
Contributor Author

ehuss commented May 10, 2018

@kennytm Ah, I'll just rebase as soon as it passes. Thanks!

@bors
Copy link
Contributor

bors commented May 11, 2018

☔ The latest upstream changes (presumably #50611) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 11, 2018
@ehuss
Copy link
Contributor Author

ehuss commented May 11, 2018

Rebased.

@alexcrichton
Copy link
Member

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented May 11, 2018

📌 Commit 2d7096f has been approved by nikomatsakis

@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 12, 2018
@ehuss
Copy link
Contributor Author

ehuss commented May 13, 2018

I've been running various docker images locally, and haven't found any more issues, yet. I figured out how to get the wasm target going, too, and it seems ok.

@rust-lang rust-lang deleted a comment from rust-highfive May 13, 2018
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented May 14, 2018

📌 Commit 598cc07 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 14, 2018
@bors
Copy link
Contributor

bors commented May 17, 2018

☔ The latest upstream changes (presumably #50807) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 17, 2018
ehuss added 4 commits May 16, 2018 22:00
- The output of each test is now in its own directory.
- "auxiliary" output is now under the respective test directory.
- `stage_id` removed from filenames, and instead placed in the stamp file as a hash.  This helps keep path lengths down for Windows.

In brief, the new layout looks like this:
```
<build_base>/<relative_dir>/<testname>.<revision>.<mode>/
    stamp
    <testname>.err
    <testname>.out
    a (binary)
    auxiliary/lib<auxname>.dylib
    auxiliary/<auxname>/<auxname>.err
    auxiliary/<auxname>/<auxname>.out
```
(revision and mode are optional)
The aux dir, which previously had the `stage_id` embedded in it, was picking up remnants from previous runs.
@ehuss
Copy link
Contributor Author

ehuss commented May 17, 2018

rebased

@kennytm kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 17, 2018
@kennytm
Copy link
Member

kennytm commented May 17, 2018

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented May 17, 2018

📌 Commit b8473de has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 17, 2018
@bors
Copy link
Contributor

bors commented May 17, 2018

⌛ Testing commit b8473de with merge e315056...

bors added a commit that referenced this pull request May 17, 2018
 compiletest: Run revisions as independent tests.

Fixes #47604.

- The output of each test is now in its own directory.
- "auxiliary" output is now under the respective test directory.
- `stage_id` removed from filenames, and instead placed in the stamp file as a hash.  This helps keep path lengths down for Windows.

In brief, the new layout looks like this:
```
<build_base>/<relative_dir>/<testname>.<revision>.<mode>/
    stamp
    <testname>.err
    <testname>.out
    a (binary)
    auxiliary/lib<auxname>.dylib
    auxiliary/<auxname>/<auxname>.err
    auxiliary/<auxname>/<auxname>.out
```
(revision and mode are optional)
@bors
Copy link
Contributor

bors commented May 17, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing e315056 to master...

@bors bors merged commit b8473de into rust-lang:master May 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants