Make the missing-const-type suggestion deterministic under the parallel front-end#157341
Open
xmakro wants to merge 2 commits into
Open
Make the missing-const-type suggestion deterministic under the parallel front-end#157341xmakro wants to merge 2 commits into
xmakro wants to merge 2 commits into
Conversation
rustbot
added
S-waiting-on-author
…el front-end When a macro expands to several items that lack a type, such as two `const A = ...;` produced by one repetition, the items all share the same empty span. The parser stashes one `ItemNoType` diagnostic per item, but stash slots are keyed by span, so only one survives and a single `type_of` query steals it. That query fills the suggestion in with the type it inferred for its own item, and under the parallel front-end which query wins the steal is nondeterministic, so the suggested type changes from run to run. The steal-failure arm already omits the suggestion for macro-expanded items because it cannot be applied to the expansion. Do the same in the steal-success arm so the output no longer depends on the race.
The missing-const-type suggestion is now deterministic, so this test no longer needs to be ignored under the parallel front-end.
xmakro
force-pushed
the
fix/parallel-item-no-type
branch
from
aea21fe to
36104a6
Compare
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-author
Collaborator
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @davidtwco (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
Why was this reviewer chosen?The reviewer was selected based on:
|
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Part of #154314. Addresses the "different infer type: bool" row.
tests/ui/consts/const-item-no-type/in-macro.rswas marked//@ ignore-parallel-frontend different infer type: bool. The test has a macro that expands to twoconst A = ...;items, one whose body infersusizeand one whose body infersbool. Both items lack a type, so the parser stashes anItemNoTypediagnostic for each, intending typeck to fill in the inferred type as a suggestion.The two items come from one macro repetition, so they share the same empty span. Stash slots are keyed by span, so the second stash overwrites the first and only one slot survives. Two
type_ofqueries then race to steal it. The winner emitsmissing type for const itemwith the type it inferred for its own item, and the loser emits the genericmissing type for item. Single threaded the first item always wins, but under the parallel front-end the winner is nondeterministic, so the suggested type flips between: usizeand: boolfrom run to run.The steal-failure arm already drops the suggestion for macro-expanded items, with a comment that the suggestion is invalid because it cannot be applied to the expansion. This makes the steal-success arm do the same, so the suggestion no longer appears for macro-expanded items and the output is stable. The only diagnostic change is that the
provide a type for the constantsuggestion is no longer shown when the item comes from a macro expansion, which is the same case the other arm already suppresses.With that the test is re-enabled. It passes single threaded and under
--parallel-frontend-threads=16 --iteration-count=300 --force-rerun. The widerconsts,suggestions,typeck, andstatictest directories pass unchanged.