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

extend compiletest to support revisions, incremental tests #32007

Merged
merged 14 commits into from
Mar 3, 2016

Conversation

nikomatsakis
Copy link
Contributor

This PR extends compiletest to support test revisions and with a preliminary incremental testing harness. run-pass, compile-fail, and run-fail tests may be tagged with

// revisions: a b c d

This will cause the test to be re-run four times with --cfg {a,b,c,d} in turn. This means you can write very closely related things using cfg. You can also configure the headers/expected-errors by writing //[foo] header: value or //[foo]~ ERROR bar, where foo is the name of your revision. See the changes to coherence-cow.rs as a proof of concept.

The main point of this work is to support the incremental testing harness. This PR contains an initial, unused version. The code that uses it will land later. The incremental testing harness compiles each revision in turn, and requires that the revisions have particular names (e.g., rpass2, cfail3), which tell it whether a particular revision is expected to compile or not.

Two questions:

  • Is there compiletest documentation anywhere I can update?
  • Should I hold off on landing the incremental testing harness until I have the code to exercise it? (That will come in a separate PR, still fixing a few details)

r? @alexcrichton
cc @rust-lang/compiler <-- new testing capabilities

@eddyb
Copy link
Member

eddyb commented Mar 2, 2016

This is great! LLVM's FileCheck has a similar feature, where you can include several test commands in a single file and a prefix for each one such that you check each of their outputs independently.

I wonder if we could extend this to work for MIR or even LLVM IR tests, to avoid depending on FileCheck.

@nikomatsakis
Copy link
Contributor Author

PS, it'd be nice if we could write automated tests for compiletest itself, but I don't know of any way to do that right now... but I have manually tested this ;)

@eddyb
Copy link
Member

eddyb commented Mar 2, 2016

@nikomatsakis Would a marker for "this test must fail (according to compiletest)" suffice?

@nikomatsakis
Copy link
Contributor Author

@eddyb I could see two things:

  • add some "metatests" into the makefile that are expected to fail
  • or add a header switch to "invert" expectations

The latter requires us still to trust compiletest, but maybe a bit less (and of course the former requires trusting makefiles, which is probably scarier).

@nikomatsakis
Copy link
Contributor Author

yeah, thinking about I like the idea of a // should-fail header. I think the meta runner of compiletest could detect and handle such a header with relative ease. I'll investigate.

@apasel422
Copy link
Contributor

@nikomatsakis There's some compiletest documentation in COMPILER_TESTS.md.

@@ -1313,6 +1392,27 @@ fn ensure_dir(path: &Path) {
fs::create_dir_all(path).unwrap();
}

fn remove_dir_and_contents(path: &Path) -> io::Result<()> {
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this just be fs::remove_dir_all?

@alexcrichton
Copy link
Member

Looks good to me, nice idea @nikomatsakis!

Implementation looks all good to me, although I didn't really audit the new incremental tests that closely. I also basically just skimmed the changes as "yep, looks like a refactor". Feel free to r=me whenever this is ready.

@nikomatsakis
Copy link
Contributor Author

Decided I might as well land the incremental runner separately. I may well need to tweak it some more, so it seems clearer to put it in the same PR as the code which uses it.

@nikomatsakis
Copy link
Contributor Author

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Mar 2, 2016

📌 Commit fff9c2b has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Mar 3, 2016

⌛ Testing commit fff9c2b with merge 356759a...

@bors
Copy link
Contributor

bors commented Mar 3, 2016

💔 Test failed - auto-linux-64-opt

@nikomatsakis
Copy link
Contributor Author

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Mar 3, 2016

📌 Commit 9601e6f has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Mar 3, 2016

⌛ Testing commit 9601e6f with merge 71669bb...

@bors
Copy link
Contributor

bors commented Mar 3, 2016

💔 Test failed - auto-linux-64-opt

@nikomatsakis
Copy link
Contributor Author

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Mar 3, 2016

📌 Commit fc4d0ec has been approved by alexcrichton

@nikomatsakis
Copy link
Contributor Author

ok, this should work now. I made the executive call that should-fail will be ignored for pretty printing tests, since usually they are checking something different than the thing which should-fail was intending to test. Another option would have to been to add // ignore-pretty to meta tests, but this seemed to be more likely to be what we want. We can add a should-fail-pretty header if we ever want that.

@bors
Copy link
Contributor

bors commented Mar 3, 2016

⌛ Testing commit fc4d0ec with merge 493d999...

bors added a commit that referenced this pull request Mar 3, 2016
…ichton

This PR extends compiletest to support **test revisions** and with a preliminary **incremental testing harness**. run-pass, compile-fail, and run-fail tests may be tagged with

```
// revisions: a b c d
```

This will cause the test to be re-run four times with `--cfg {a,b,c,d}` in turn. This means you can write very closely related things using `cfg`. You can also configure the headers/expected-errors by writing `//[foo] header: value` or `//[foo]~ ERROR bar`, where `foo` is the name of your revision. See the changes to `coherence-cow.rs` as a proof of concept.

The main point of this work is to support the incremental testing harness. This PR contains an initial, unused version. The code that uses it will land later. The incremental testing harness compiles each revision in turn, and requires that the revisions have particular names (e.g., `rpass2`, `cfail3`), which tell it whether a particular revision is expected to compile or not.

Two questions:

- Is there compiletest documentation anywhere I can update?
- Should I hold off on landing the incremental testing harness until I have the code to exercise it? (That will come in a separate PR, still fixing a few details)

r? @alexcrichton
cc @rust-lang/compiler <-- new testing capabilities
@bors bors merged commit fc4d0ec into rust-lang:master Mar 3, 2016
@nikomatsakis nikomatsakis deleted the compiletest-incremental branch March 30, 2016 16:12
bors added a commit that referenced this pull request Apr 6, 2016
Save/load incremental compilation dep graph

Contains the code to serialize/deserialize the dep graph to disk between executions. We also hash the item contents and compare to the new hashes. Also includes a unit test harness. There are definitely some known limitations, such as #32014 and #32015, but I am leaving those for follow-up work.

Note that this PR builds on #32007, so the overlapping commits can be excluded from review.

r? @michaelwoerister
bors added a commit that referenced this pull request Apr 7, 2016
Save/load incremental compilation dep graph

Contains the code to serialize/deserialize the dep graph to disk between executions. We also hash the item contents and compare to the new hashes. Also includes a unit test harness. There are definitely some known limitations, such as #32014 and #32015, but I am leaving those for follow-up work.

Note that this PR builds on #32007, so the overlapping commits can be excluded from review.

r? @michaelwoerister
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants