-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spans for Paths can be incorrect #39450
Comments
We've had the same issue in clippy: https://github.com/Manishearth/rust-clippy/issues/1404#issuecomment-275861252 copying over the comment:
|
cc #23480 |
macros: improve `Span`'s expansion information This PR improves `Span`'s expansion information. More specifically: - It refactors AST node span construction to preserve expansion information. - Today, we only use the underlying tokens' `BytePos`s, throwing away the `ExpnId`s. - This improves the accuracy of AST nodes' expansion information, fixing #30506. - It refactors `span.expn_id: ExpnId` to `span.ctxt: SyntaxContext` and removes `ExpnId`. - This gives all tokens as much hygiene information as `Ident`s. - This is groundwork for procedural macros 2.0 `TokenStream` API. - This is also groundwork for declarative macros 2.0, which will need this hygiene information for some non-`Ident` tokens. - It simplifies processing of spans' expansion information throughout the compiler. - It fixes #40649. - It fixes #39450 and fixes part of #23480. r? @nrc
Consider the following example (from term-painter):
On the third line are two paths of the form
fmt::$fmt
, after expansion, these are bothfmt::Display
. The way spans for paths are calculated we take the start offmt
and the end ofDisplay
(seeparse_path
in parser.rs), this means the span for the path is 9 lines long and pretty incoherent. Annoyingly, this span does not get an expansion id, and thus has no indication that it came from generated code. This is visible in error messages:The text was updated successfully, but these errors were encountered: