[ui tests]: Normalize away THIR end span for output stability#151693
Closed
jyn514 wants to merge 1 commit intorust-lang:mainfrom
Closed
[ui tests]: Normalize away THIR end span for output stability#151693jyn514 wants to merge 1 commit intorust-lang:mainfrom
jyn514 wants to merge 1 commit intorust-lang:mainfrom
Conversation
Spans for the `offset_of!` builtin macro point into an arbitrary place in `core::mem`. This means that the test has to be re-blessed whenever `core/src/mem/mod.rs` line numbers change. Ideally, Span printing would be smarter and wouldn't show an end span if it came from a different crate than the start span (or maybe truncated the span to the last place in the start's crate). But that's a more involved fix and this avoids the immediate problem.
rustbot
added
S-waiting-on-review
Collaborator
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 8, 2026
Avoid a bogus THIR span for `let x = offset_of!(..)` The code that creates spans for THIR `let` statements was doing span endpoint manipulation without checking for inclusion/context, resulting in bogus spans observed in #151693. The incorrect spans are easiest to observe with `-Zunpretty=thir-tree`, but they also cause strange user-facing diagnostics for irrefutable let-else.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Feb 8, 2026
…cote Avoid a bogus THIR span for `let x = offset_of!(..)` The code that creates spans for THIR `let` statements was doing span endpoint manipulation without checking for inclusion/context, resulting in bogus spans observed in rust-lang#151693. The incorrect spans are easiest to observe with `-Zunpretty=thir-tree`, but they also cause strange user-facing diagnostics for irrefutable let-else.
rust-timer
added a commit
that referenced
this pull request
Feb 8, 2026
Rollup merge of #152284 - Zalathar:bogus-thir-let, r=nnethercote Avoid a bogus THIR span for `let x = offset_of!(..)` The code that creates spans for THIR `let` statements was doing span endpoint manipulation without checking for inclusion/context, resulting in bogus spans observed in #151693. The incorrect spans are easiest to observe with `-Zunpretty=thir-tree`, but they also cause strange user-facing diagnostics for irrefutable let-else.
Contributor
|
☔ The latest upstream changes (presumably #152314) made this pull request unmergeable. Please resolve the merge conflicts. |
Member
Author
|
fixed more thoroughly in #152284 |
rustbot
removed
the
S-waiting-on-review
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.
Spans for the
offset_of!builtin macro point into an arbitrary place incore::mem. This means that the test has to be re-blessed whenevercore/src/mem/mod.rsline numbers change.Ideally, Span printing would be smarter and wouldn't show an end span if it came from a different crate than the start span (or maybe truncated the span to the last place in the start's crate). But that's a more involved fix and this avoids the immediate problem.
For transparency: This PR is mostly to make Ferrocene's CI break less often. But I expect it to also be useful upstream.