Try_run must only be used if toolstate is populated #73097
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit 6f01576 has been approved by |
bors
added
S-waiting-on-bors
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Jun 11, 2020
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.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 11, 2020
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 |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 16, 2020
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.