diagnostics: fix let x: vec![] suggestion pointing into stdlib - #158934
Open
Rohan-Singla wants to merge 1 commit into
Open
diagnostics: fix let x: vec![] suggestion pointing into stdlib#158934Rohan-Singla wants to merge 1 commit into
let x: vec![] suggestion pointing into stdlib#158934Rohan-Singla wants to merge 1 commit into
Conversation
Collaborator
|
HIR ty lowering was modified cc @fmease |
rustbot
added
S-waiting-on-review
Collaborator
|
r? @jackh726 rustbot has assigned @jackh726. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Rohan-Singla
changed the title
let x: vec![] suggestion pointing into stdlib
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Member
|
Hi, can you please take a look at this review #158509 (review). |
Contributor
Author
Thanks for the feedback! Switched from source_callsite() to find_ancestor_in_same_ctxt the old approach jumped too far back in the expansion chain. Added a helper eq_ctxt_suggestion_span that tries to find ancestors of pat and ty in each other's syntax context, only emitting the suggestion when both spans can be reconciled in the same context. Also added a test for the macro case which was pointed out it now correctly emits no suggestion instead of make!( = ). |
Contributor
Author
This comment has been minimized.
This comment has been minimized.
Member
|
Sorry for the delay. r=me after rebase |
Rohan-Singla
force-pushed
the
fix/158492
branch
from
August 19, 2026 17:15
23798ce to
7e1f33d
Compare
Collaborator
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
When a macro call like `vec![]` appears in type position, the compiler's "use `=` if you meant to assign" suggestion was pointing into the macro definition in stdlib instead of the user's own code. The suggestion span was computed as `stmt.pat.span.between(hir_ty.span)`. After expansion `hir_ty.span` lies inside the macro body, so that span crossed syntax contexts and the renderer displayed the stdlib location. Compute the span via `find_ancestor_in_same_ctxt` instead, so the pattern and the type are compared in a common syntax context. When no common context exists -- e.g. the `let` comes from a macro body while the pattern is a call-site metavariable -- no suggestion is emitted at all.
Rohan-Singla
force-pushed
the
fix/158492
branch
from
August 19, 2026 17:22
7e1f33d to
f151cb9
Compare
Contributor
Author
Hey Jack , no worried i have rebased the code and fixed the conflicts i have also updated the PR description would encourage you to have a look at it . r? @jackh726 Thanks! |
Collaborator
|
Requested reviewer is already assigned to this pull request. Please choose another assignee. |
Member
|
@bors r+ |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Member
|
please, disclose llm usage, we have new policy that requires it |
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 20, 2026
diagnostics: fix `let x: vec![]` suggestion pointing into stdlib # Fixes rust-lang#158492 When a macro call like `vec![]` appears in type position (`let x: vec![];`), the compiler correctly detects the likely typo (`:` instead of `=`), but emits a broken suggestion pointing into the standard library (`library/alloc/src/macros.rs:44`) instead of the user's own code. ## Root cause After macro expansion, `vec![]` becomes `Vec::new()`. The HIR type node's span therefore points to the expanded code inside the macro definition rather than the original `vec![]` call site. The suggestion span was computed as: `stmt.pat.span.between(hir_ty.span)` This creates a span crossing from the user's code into the standard library, causing the suggestion renderer to display the standard library location. ## Fix Compute the span using `find_ancestor_in_same_ctxt` so that the pattern and type are resolved into a common syntax context before calling `between`. For `let x: vec![];`, this walks the type's span up the expansion chain until it reaches the user's file, keeping the suggestion within a single file. This also handles the reverse case, which `source_callsite` alone does not: when the `let` itself comes from a macro body while the pattern is a call-site metavariable, there is no common context. In that case, no suggestion is emitted rather than producing a nonsensical one. ## Before ```text help: use `=` if you meant to assign --> library/alloc/src/macros.rs:44:9 | 44 - $crate::vec::Vec::new() 44 + = ``` ## After ```text help: use `=` if you meant to assign | LL - let x: vec![]; LL + let x = vec![]; ``` ## Tests Two test cases were added to `tests/ui/suggestions/let-binding-init-expr-as-ty.rs`, which already covers the related `let x: Vec::new()` and `let x: S::new(())` cases: 1. The `vec![]` case described above. 2. A `let` inside a `macro_rules!` body where no suggestion should be emitted. ## Note on file layout The new `eq_ctxt_suggestion_span` helper lives in `hir_ty_lowering/errors.rs` rather than next to its callers in `mod.rs`. `mod.rs` was already within a few lines of tidy's 3000-line limit, so keeping the helper there caused the style check to fail. This is pure code motion with no behavior change.
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 20, 2026
diagnostics: fix `let x: vec![]` suggestion pointing into stdlib # Fixes rust-lang#158492 When a macro call like `vec![]` appears in type position (`let x: vec![];`), the compiler correctly detects the likely typo (`:` instead of `=`), but emits a broken suggestion pointing into the standard library (`library/alloc/src/macros.rs:44`) instead of the user's own code. ## Root cause After macro expansion, `vec![]` becomes `Vec::new()`. The HIR type node's span therefore points to the expanded code inside the macro definition rather than the original `vec![]` call site. The suggestion span was computed as: `stmt.pat.span.between(hir_ty.span)` This creates a span crossing from the user's code into the standard library, causing the suggestion renderer to display the standard library location. ## Fix Compute the span using `find_ancestor_in_same_ctxt` so that the pattern and type are resolved into a common syntax context before calling `between`. For `let x: vec![];`, this walks the type's span up the expansion chain until it reaches the user's file, keeping the suggestion within a single file. This also handles the reverse case, which `source_callsite` alone does not: when the `let` itself comes from a macro body while the pattern is a call-site metavariable, there is no common context. In that case, no suggestion is emitted rather than producing a nonsensical one. ## Before ```text help: use `=` if you meant to assign --> library/alloc/src/macros.rs:44:9 | 44 - $crate::vec::Vec::new() 44 + = ``` ## After ```text help: use `=` if you meant to assign | LL - let x: vec![]; LL + let x = vec![]; ``` ## Tests Two test cases were added to `tests/ui/suggestions/let-binding-init-expr-as-ty.rs`, which already covers the related `let x: Vec::new()` and `let x: S::new(())` cases: 1. The `vec![]` case described above. 2. A `let` inside a `macro_rules!` body where no suggestion should be emitted. ## Note on file layout The new `eq_ctxt_suggestion_span` helper lives in `hir_ty_lowering/errors.rs` rather than next to its callers in `mod.rs`. `mod.rs` was already within a few lines of tidy's 3000-line limit, so keeping the helper there caused the style check to fail. This is pure code motion with no behavior change.
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
4 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.
Fixes #158492
When a macro call like
vec![]appears in type position (let x: vec![];), the compiler correctly detects the likely typo (:instead of=), but emits a broken suggestion pointing into the standard library (library/alloc/src/macros.rs:44) instead of the user's own code.Root cause
After macro expansion,
vec![]becomesVec::new(). The HIR type node's span therefore points to the expanded code inside the macro definition rather than the originalvec![]call site.The suggestion span was computed as:
stmt.pat.span.between(hir_ty.span)This creates a span crossing from the user's code into the standard library, causing the suggestion renderer to display the standard library location.
Fix
Compute the span using
find_ancestor_in_same_ctxtso that the pattern and type are resolved into a common syntax context before callingbetween.For
let x: vec![];, this walks the type's span up the expansion chain until it reaches the user's file, keeping the suggestion within a single file.This also handles the reverse case, which
source_callsitealone does not: when theletitself comes from a macro body while the pattern is a call-site metavariable, there is no common context. In that case, no suggestion is emitted rather than producing a nonsensical one.Before
After
Tests
Two test cases were added to
tests/ui/suggestions/let-binding-init-expr-as-ty.rs, which already covers the relatedlet x: Vec::new()andlet x: S::new(())cases:vec![]case described above.letinside amacro_rules!body where no suggestion should be emitted.Note on file layout
The new
eq_ctxt_suggestion_spanhelper lives inhir_ty_lowering/errors.rsrather than next to its callers inmod.rs.mod.rswas already within a few lines of tidy's 3000-line limit, so keeping the helper there caused the style check to fail.This is pure code motion with no behavior change.