Remove vestigial CI job msvc-aux. #73296
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
How |
|
Oh, good question! It looks like the valgrind tests silently downgrade to just a normal run-pass test. AFAIK, none of the CI jobs use valgrind. |
|
So just to make sure I understand, this isn't technically changing behavior but is sort of just affirming that pretty tests aren't being run? It seems like we should duplicate/move the pretty tests to src/test/pretty at least? |
|
I'm not sure I'm understanding your questions correctly, as I'm somewhat unfamiliar with some of this. IIUC, the pretty tests just ingest some code and verify the pretty printer spits out something that can still compile (modulo other annotations like compare-only). I'm not sure if there are any tests to "move". Previously the test suite used various parts of the Does that sound like a correct summary? I don't think there was anything special about I just tried to run pretty tests on I'm not sure how pretty-printing tests should be handled moving forward. I'm inclined to say new tests should be added to |
|
Okay, thanks. I also took a look a the specific tests in question and it looks like there's not really anything special with regards to pretty printing there. #23616 (comment) also makes me feel like maybe we should just remove all the pretty annotations and create some tests which are specifically intended to test pretty printing (if we even care about it all that much). I think the primary reason for wanting to test pretty printing is that proc macros currently sometimes fall back on it as a method for generating tokenstreams, but we're moving away from that model over time. We also sometimes use it in diagnostics, but those should be tested with dedicated UI tests for the most part rather than pretty tests, I think. But, regardless of the ultimate fate of pretty tests, I agree that losing the run-pass-valgrind suite isn't going to hurt us, so I'm going to go ahead and approve this. cc @pietroalbini -- this frees up a builder slot for us which might be good for the limits you mentioned we might be hitting soon. @bors r+ |
|
📌 Commit c0aef6d has been approved by |
bors
added
S-waiting-on-bors
|
@bors rollup |
…acrum Remove vestigial CI job msvc-aux. This CI job isn't really doing anything, so it seems prudent to remove it. For some history: * This was introduced in rust-lang#48809 when the msvc job was split in two to keep it under 2 hours (oh the good old days). At the time, this check-aux job did a bunch of things: * tidy * src/test/pretty * src/test/run-pass/pretty * src/test/run-fail/pretty * src/test/run-pass-valgrind/pretty * src/test/run-pass-fulldeps/pretty * src/test/run-fail-fulldeps/pretty * Tidy was removed in rust-lang#60777. * run-pass and run-pass-fulldeps moved to UI in rust-lang#63029 * src/test/pretty removed in rust-lang#58140 * src/test/run-fail moved to UI in rust-lang#71185 * run-fail-fulldeps removed in rust-lang#51285 Over time through attrition, the job was left with one lonely thing: `src/test/run-pass-valgrind/pretty`. And of course, this wasn't actually running the "pretty" tests. The normal `run-pass-valgrind` tests ran, and then when it tried to run in "pretty" mode, all the tests were ignored because compiletest thought nothing had changed (apparently compiletest isn't fingerprinting the mode? Needs more investigation…). `run-pass-valgrind` is already being run as part of `x86_64-msvc-1`, so there's no need to run it here. I've taken the liberty of removing `src/test/run-pass-valgrind/pretty` as a distinct test. I'm guessing from the other PR's that the pretty tests should now live in `src/test/pretty`, and that the team has moved away from doing pretty tests on other parts of the `src/test` tree.
Rollup of 10 pull requests Successful merges: - rust-lang#72707 (Use min_specialization in the remaining rustc crates) - rust-lang#72740 (On recursive ADT, provide indirection structured suggestion) - rust-lang#72879 (Miri: avoid tracking current location three times) - rust-lang#72938 (Stabilize Option::zip) - rust-lang#73086 (Rename "cyclone" to "apple-a7" per changes in upstream LLVM) - rust-lang#73104 (Example about explicit mutex dropping) - rust-lang#73139 (Add methods to go from a nul-terminated Vec<u8> to a CString) - rust-lang#73296 (Remove vestigial CI job msvc-aux.) - rust-lang#73304 (Revert heterogeneous SocketAddr PartialEq impls) - rust-lang#73331 (extend network support for HermitCore) Failed merges: r? @ghost
This CI job isn't really doing anything, so it seems prudent to remove it.
For some history:
test/run-failto UI #71185Over time through attrition, the job was left with one lonely thing:
src/test/run-pass-valgrind/pretty. And of course, this wasn't actually running the "pretty" tests. The normalrun-pass-valgrindtests ran, and then when it tried to run in "pretty" mode, all the tests were ignored because compiletest thought nothing had changed (apparently compiletest isn't fingerprinting the mode? Needs more investigation…).run-pass-valgrindis already being run as part ofx86_64-msvc-1, so there's no need to run it here.I've taken the liberty of removing
src/test/run-pass-valgrind/prettyas a distinct test. I'm guessing from the other PR's that the pretty tests should now live insrc/test/pretty, and that the team has moved away from doing pretty tests on other parts of thesrc/testtree.