-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Conversation
a test file may specify `// revisions: foo bar baz` headers and expected errors may be made specific to a revision by writing `//[foo] header` or `//[foo]~ ERROR`
5189446
to
dee6853
Compare
This is great! LLVM's I wonder if we could extend this to work for MIR or even LLVM IR tests, to avoid depending on |
PS, it'd be nice if we could write automated tests for |
@nikomatsakis Would a marker for "this test must fail (according to |
@eddyb I could see two things:
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). |
yeah, thinking about I like the idea of a |
@nikomatsakis There's some compiletest documentation in |
@@ -1313,6 +1392,27 @@ fn ensure_dir(path: &Path) { | |||
fs::create_dir_all(path).unwrap(); | |||
} | |||
|
|||
fn remove_dir_and_contents(path: &Path) -> io::Result<()> { |
There was a problem hiding this comment.
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
?
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. |
and write a really basic "meta test" of the compilertest framework
f36f73d
to
fff9c2b
Compare
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. |
@bors r=alexcrichton |
📌 Commit fff9c2b has been approved by |
⌛ Testing commit fff9c2b with merge 356759a... |
💔 Test failed - auto-linux-64-opt |
@bors r=alexcrichton |
📌 Commit 9601e6f has been approved by |
⌛ Testing commit 9601e6f with merge 71669bb... |
💔 Test failed - auto-linux-64-opt |
@bors r=alexcrichton |
📌 Commit fc4d0ec has been approved by |
ok, this should work now. I made the executive call that |
…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
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
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
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
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 usingcfg
. You can also configure the headers/expected-errors by writing//[foo] header: value
or//[foo]~ ERROR bar
, wherefoo
is the name of your revision. See the changes tocoherence-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:
r? @alexcrichton
cc @rust-lang/compiler <-- new testing capabilities