-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Try_run must only be used if toolstate is populated #73097
Conversation
Clippy's tests were failing the build, but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools, but Clippy no longer updates its toolstate status as it should always build.
@bors r+ |
📌 Commit 6f01576 has been approved by |
Try_run must only be used if toolstate is populated Clippy's tests were failing the build, but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools, but Clippy no longer updates its toolstate status as it should always build. The previous PR of this kind didn't catch this as I expected x.py failures to always lead to a non-successful build in CI, but that's not the case specifically for tool testing.
Rollup of 7 pull requests Successful merges: - rust-lang#72180 (remove extra space from crate-level doctest names) - rust-lang#73012 (Show `SyntaxContext` in formatted `Span` debug output) - rust-lang#73097 (Try_run must only be used if toolstate is populated) - rust-lang#73169 (Handle assembler warnings properly) - rust-lang#73182 (Track span of function in method calls, and use this in #[track_caller]) - rust-lang#73207 (Clean up E0648 explanation) - rust-lang#73230 (Suggest including unused asm arguments in a comment to avoid error) Failed merges: r? @ghost
I think this broke toolstate tracking: #73274 |
This PR solely touches clippy, not sure how it could have broken miri |
The rollup where this landed (#73246) also marked rls and rustfmt as non-broken, which is probably bogus. It could be another PR in that rollup, but this seemed the most likely... |
Or maybe rls and rustfmt actually were fixed, and that rollup has nothing to do with #73274, and something else broke Miri toolstate tracking? |
No, I just checked the logs and there are build errors for rls See the log entry for rls: https://dev.azure.com/rust-lang/rust/_build/results?buildId=31744&view=logs&j=396dc680-0b3a-5910-2395-0c692e01f85b&t=2ca6b3c4-04bf-58c0-3d82-f09735e43e8e&l=11983 |
…ng,oli-obk Avoid prematurely recording toolstates When we're running with dry_run enabled (i.e. all builds do this initially), we're guaranteed to save of a toolstate of TestFail for tools that aren't tested. In practice, we do test tools as well, so for those tools we would initially record them as being TestPass, and then later on re-record the correct state after actually testing them. However, this would not work well if the build failed for whatever reason (e.g. panicking in bootstrap, or as was the case in rust-lang#73097, clippy failing to test successfully), we would just go on believing that things passed when they in practice did not. This commit also adjusts saving toolstate to never record clippy explicitly (otherwise, it would be recorded when building it); eventually that'll likely move to other tools as well but not yet. This is deemed simpler than checking everywhere we generically save toolstate. We also move clippy out of the "toolstate" no-fail-fast build into a separate x.py invocation; this should no longer be technically required but provides the nice state of letting us check toolstate for all tools and only then check clippy (giving full results on every build). r? @oli-obk Supercedes rust-lang#73275, also fixes rust-lang#73274
Clippy's tests were failing the build, but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools, but Clippy no longer updates its toolstate status as it should always build.
The previous PR of this kind didn't catch this as I expected x.py failures to always lead to a non-successful build in CI, but that's not the case specifically for tool testing.