-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Pretty-printing/tokenization of final
has changed to r#final
#62628
Comments
I think we probably threaded through a is_raw_guess somewhere we didn't before. I think it's this code: https://github.com/rust-lang/rust/pull/62393/files#diff-c82811a081b5fb219ba68dd88b49d0b1R670. Previously we'd just directly stringify so |
This fixes an issue also reported to upstream (rust-lang/rust#62628) to ensure that we parse the `final` attribute as either `r#final` or `final`, since now the compiler is giving us `r#final` and we were previously only accepting `final`. The parsing here was a bit wonky, but this setup ended up working!
This looks like a bug, I assumed that |
I'll look into more detail today. |
This is indeed the case and it's trivially fixable, but the trivial fix regresses formatting of the pretty-printed code. |
Fixed in #62667. |
pprust: Improve pretty-printing of delimited token groups The commit "Do not convert attributes into `MetaItem`s for printing" fixes #62628. Other commits fix regressions from abandoning `MetaItem`s, and make formatting for attributes, macro calls, macro definitions and other delimited token groups better and more consistent. r? @Mark-Simulacrum
Thanks for the quick fix @petrochenkov! |
Given a procedural macro like:
and a consumer like:
This previously compiled and succeeded on nightly-2019-07-10 but fails on nightly-2017-07-11. Bisection yields #62555 as the culprit of which #62393 is the likely true culprit.
When running if you set
RUSTC_LOG=syntax
you get:which I believe means that the compiler is pretty-printing the identifier in macros as
r#final
instead offinal
.For reference this is a pretty minimized scenario but it has broken
wasm-bindgen
's test suite (which uses#[wasm_bindgen(final)]
throughout). @petrochenkov is this intentional? Is this something that should be fixed or "the macro parser needs to be update"?(I'm gonna update the parser anyway but wanted to be sure to file an issue as well)
The text was updated successfully, but these errors were encountered: