Fast rerun #156
Fast rerun #156
Conversation
…lter the test. This makes adding more things easier
|
So what's the logic here -- ui_test keeps track of a timestamp file, and if a test is older than that file it gets rerun? Also if the test binary changes everything gets rerun? I guess that works for Miri since the compiletest binary actually links against Miri even though it doesn't have to... not sure if it will work in other cases. But I also don't have a better idea. If a test failed last time, then rustc compiletest always reruns it. That seems preferable since otherwise, the test suite can seem to pass (thanks to ignoring all failed tests) when it shouldn't pass. That logic is currently missing here, or did I misunderstand the code? |
src/lib.rs
Outdated
|
|
||
| // Make sure the `default_file_filter` recognizes that the test has already been run successfully | ||
| // and avoid running it again. | ||
| let check_file = config.out_dir.join(path.with_extension("timestamp")); | ||
| std::fs::create_dir_all(check_file.parent().unwrap()).unwrap(); | ||
| std::fs::File::create(check_file).unwrap(); |
There was a problem hiding this comment.
If a test failed last time, then rustc compiletest always reruns it.
This also happens here, but I realize now that we have an early success path for run tests 🙃 so run tests are always run again
|
hmm... I just realized that this won't detect if an aux-build file changes 🙃 edit: or if the crates.io dependencies change... |
|
Ah, makes sense, thanks! LGTM, though I'll only actually be sure when this gets tested for real...^^
Ah, and that.^^ |
|
There's some tricky cases in clippy like the #[path = auxiliary/foo.rs]
mod foo;include_str("foo.txt");This all should be contained in the depinfo file but handling that is a jump in complexity |
|
Ah yeah, Miri also uses something like that. |
fixes #143
cc @RalfJung