-
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
syntax: Avoid span arithmetic for delimiter tokens #66054
Conversation
| | ||
LL | fn i(n{...,f # | ||
| ^ expected `[` | ||
| ^ expected `[` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May I ask is the extra space expected behavior? I wasn't sure which caused this extra space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, perhaps lexer considers the newline a one more character (so span of the recovered closing delimiter is at EOF after the newline), but error rendering still puts the label on the same line?
@bors r+ |
📌 Commit 90f891d has been approved by |
syntax: Avoid span arithmetic for delimiter tokens The +/-1 logic is from the time where the whole group had a single span and the delimiter spans had to be calculated from it. Now the delimiters have their own spans which are constructed by lexer or proc macro API and can be used directly. If those spans are not perfect, then it should be fixed by tweaking the corresponding lexer logic rather than by trying to add or substract `1` from the span boundaries. Fixes rust-lang#62524 r? @estebank
syntax: Avoid span arithmetic for delimiter tokens The +/-1 logic is from the time where the whole group had a single span and the delimiter spans had to be calculated from it. Now the delimiters have their own spans which are constructed by lexer or proc macro API and can be used directly. If those spans are not perfect, then it should be fixed by tweaking the corresponding lexer logic rather than by trying to add or substract `1` from the span boundaries. Fixes rust-lang#62524 r? @estebank
Rollup of 11 pull requests Successful merges: - #65892 (Remove `PartialEq` and `Eq` from the `SpecialDerives`.) - #66014 (Show type parameter name and definition in type mismatch error messages ) - #66027 (Move has_panic_handler to query) - #66054 (syntax: Avoid span arithmetic for delimiter tokens) - #66068 (use silent emitter for rustdoc highlighting pass) - #66081 (let caller of check_ptr_access_align control the error message) - #66093 (Do not ICE with a precision flag in formatting str and no format arguments) - #66098 (Detect `::` -> `:` typo when involving turbofish) - #66101 (Tweak type mismatch caused by break on tail expr) - #66106 (Fix typo in explanation of `E0080`) - #66115 (rustc: remove "GlobalMetaData" dead code from hir::map::definitions.) Failed merges: r? @ghost
Add more tests for fixed ICEs Closes rust-lang#36122 (fixed in 1.20.0) Closes rust-lang#58094 (fixed in rust-lang#66054) Also, fix mistaken test case, from rust-lang#30904 to rust-lang#30906 (cc @eddyb) r? @Centril
Add more tests for fixed ICEs Closes rust-lang#36122 (fixed in 1.20.0) Closes rust-lang#58094 (fixed in rust-lang#66054) Also, fix mistaken test case, from rust-lang#30904 to rust-lang#30906 (cc @eddyb) r? @Centril
Add more tests for fixed ICEs Closes rust-lang#36122 (fixed in 1.20.0) Closes rust-lang#58094 (fixed in rust-lang#66054) Also, fix mistaken test case, from rust-lang#30904 to rust-lang#30906 (cc @eddyb) r? @Centril
The +/-1 logic is from the time where the whole group had a single span and the delimiter spans had to be calculated from it.
Now the delimiters have their own spans which are constructed by lexer or proc macro API and can be used directly.
If those spans are not perfect, then it should be fixed by tweaking the corresponding lexer logic rather than by trying to add or substract
1
from the span boundaries.Fixes #62524
r? @estebank