Conversation
Zalathar
added
the
A-contributor-roadblock
rustbot
added
S-waiting-on-review
Collaborator
|
r? @mati865 rustbot has assigned @mati865. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Member
Author
Member
Author
|
I was originally going to do something like #153159 and delete a bunch of trailing semicolons throughout the compiler (since that also seems to work around the problem), but then I noticed that I could tweak the macros instead, which is a much smaller change. |
Member
Author
|
Ah, this would certainly explain things: (found by @khyperia) I guess we mostly get away with it because the compiler has very few macros-2 macros that don't override hygiene anyway, and for the remaining exceptions it usually doesn't end up causing problems. |
For whatever reason, rust-analyzer doesn't understand hygienic macros well enough to properly resolve this function call, which leads to bogus type errors appearing in rust-analyzer because it doesn't know that the function returns `!` and therefore must diverge. (For example, if `bug!(..);` with a trailing semicolon is used in the else block of a let-else statement, rust-analyzer will complain about it even though rustc is happy.) If we specify the full path to the function, both rustc and rust-analyzer agree that it diverges.
Member
|
aah nice thank you, I've been so annoyed by rust-analyzer here! r=me when ci is green (sorry for asking you to change |
Member
Author
|
PR CI is green. @bors r=khyperia rollup |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 20, 2026
Use the full path of `bug_impl` to avoid bogus errors in rust-analyzer For whatever reason, rust-analyzer doesn't understand hygienic macros well enough to properly resolve this function call, which leads to bogus type errors appearing in rust-analyzer because it doesn't know that the function returns `!` and therefore must diverge. (For example, if `bug!(..);` with a trailing semicolon is used in the else block of a let-else statement, rust-analyzer will complain about it even though rustc is happy.) If we specify the full path to the function, both rustc and rust-analyzer agree that it diverges. --- I noticed this problem when rust-analyzer started flagging a lot more bogus warnings after rust-lang#161873. Thankfully the workaround is very simple, so we don't really lose much by catering to rust-analyzer here. There should be no change to compiler behaviour.
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 20, 2026
Use the full path of `bug_impl` to avoid bogus errors in rust-analyzer For whatever reason, rust-analyzer doesn't understand hygienic macros well enough to properly resolve this function call, which leads to bogus type errors appearing in rust-analyzer because it doesn't know that the function returns `!` and therefore must diverge. (For example, if `bug!(..);` with a trailing semicolon is used in the else block of a let-else statement, rust-analyzer will complain about it even though rustc is happy.) If we specify the full path to the function, both rustc and rust-analyzer agree that it diverges. --- I noticed this problem when rust-analyzer started flagging a lot more bogus warnings after rust-lang#161873. Thankfully the workaround is very simple, so we don't really lose much by catering to rust-analyzer here. There should be no change to compiler behaviour.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 20, 2026
…uwer Rollup of 15 pull requests Successful merges: - #162726 (std: fix unix socket address panic on a full sun_path) - #163016 (Don't claim that escaping value is a reference in diagnostics) - #163040 (Tweak "use array's length as const param" suggestion) - #163060 (Point to fields that introduce trait requirements) - #163066 (don't mark `f128` as reliable on AIX) - #162098 (Tweak `Infallible` docs) - #162854 (Add safety section for atomic_load/store) - #163015 (add `minicore::ffi::VaList`) - #163021 (`va_arg`: pass in `TyAndLayout`) - #163036 ([rustdoc] Correctly handle `dyn` trait methods linking for jump to def feature) - #163042 (Remove redundant output from suggestion) - #163046 (Use verbose suggestion for `const _`) - #163050 (Use verbose suggestion for similarly named label suggestion) - #163052 (Use verbose suggestion for wrong primitive type names) - #163055 (Use the full path of `bug_impl` to avoid bogus errors in rust-analyzer)
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.
For whatever reason, rust-analyzer doesn't understand hygienic macros well enough to properly resolve this function call, which leads to bogus type errors appearing in rust-analyzer because it doesn't know that the function returns
!and therefore must diverge.(For example, if
bug!(..);with a trailing semicolon is used in the else block of a let-else statement, rust-analyzer will complain about it even though rustc is happy.)If we specify the full path to the function, both rustc and rust-analyzer agree that it diverges.
I noticed this problem when rust-analyzer started flagging a lot more bogus warnings after #161873. Thankfully the workaround is very simple, so we don't really lose much by catering to rust-analyzer here.
There should be no change to compiler behaviour.