-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Recursively expand TokenKind::Interpolated
in probably_equal_for_proc_macro
#72388
Recursively expand TokenKind::Interpolated
in probably_equal_for_proc_macro
#72388
Conversation
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit e3d3b4d2f56d8f6c3aaba1fc10d79d74a1bf6296 with merge 7a63e056b52f40554fc1c032eac566fa6b26d9ce... |
LGTM, but need to check perf. |
☀️ Try build successful - checks-azure |
Queued 7a63e056b52f40554fc1c032eac566fa6b26d9ce with parent 06c9fef, future comparison URL. |
Finished benchmarking try commit 7a63e056b52f40554fc1c032eac566fa6b26d9ce, comparison URL. |
@petrochenkov: It looks like perf is unchanged |
@bors r+ |
📌 Commit e3d3b4d2f56d8f6c3aaba1fc10d79d74a1bf6296 has been approved by |
This comment has been minimized.
This comment has been minimized.
e3d3b4d
to
4d260dd
Compare
4d260dd
to
5685e4d
Compare
* Handle the possibility that the class name is in its own Group rust-lang/rust#72388 makes this happen * Handle Groups in more places * fmt! * Add some functions to handle Groups As suggested by @alexcrichton [here](https://gist.github.com/alexcrichton/3c93ab2547d45d9caa3b72309cd4262b).
…, r=petrochenkov Revert recursive `TokenKind::Interpolated` expansion for now The crater run rust-lang#72622 revealed many root regressions, at least one of which is going to take some time to fix. For now, let's revert rust-lang#72388 to allow the 709 affected crates to continue building on the latest nightly.
When rust-lang/rust#72388 re-lands, we may accumulate several 'layers' of `None`-delimited groups. This commit ensures that we 'unwrap' all of the layers, allowing consumers to avoid needing to handle these cases.
Fixes rust-lang#68430 This is a re-attempt of PR rust-lang#72388, which was previously reverted due to a large number of breakages. All of the known breakages should now be patched upstream.
…d, r=petrochenkov Re-land PR rust-lang#72388: Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro` PR rust-lang#72388 allowed us to preserve the original `TokenStream` in more cases during proc-macro expansion, but had to be reverted due to a large number of regressions (See rust-lang#72545 and rust-lang#72622). These regressions fell into two categories 1. Missing handling for `Group`s with `Delimiter::None`, which are inserted during `macro_rules!` expansion (but are lost during stringification and re-parsing). A large number of these regressions were due to `syn` and `proc-macro-hack`, but several crates needed changes to their own proc-macro code. 2. Legitimate hygiene issues that were previously being masked by stringification. Some of these were relatively benign (e.g. [a compiliation error](paritytech/parity-scale-codec#210) caused by misusing `quote_spanned!`). However, two crates had intentionally written unhygenic `macro_rules!` macros, which were able to access identifiers that were not passed as arguments (see rust-lang#72622 (comment)). All but one of the Crater regressions have now been fixed upstream (see https://hackmd.io/ItrXWRaSSquVwoJATPx3PQ?both). The remaining crate (which has a PR pending at sammhicks/face-generator#1) is not on `crates.io`, and is a Yew application that seems unlikely to have any reverse dependencies. As @petrochenkov mentioned in rust-lang#72545 (comment), not re-landing PR rust-lang#72388 allows more crates to write unhygenic `macro_rules!` macros, which will eventually stop compiling. Since there is only one Crater regression remaining, since additional crates could write unhygenic `macro_rules!` macros in the time it takes that PR to be merged.
Fixes #68430
When comparing the captured and re-parsed
TokenStream
for aTokenKind::Interpolated
, we currently treat any nestedTokenKind::Interpolated
tokens as unequal. If aTokenKind::Interpolated
token shows up in the capturedTokenStream
due to amacro_rules!
expansion, we will throw away the capturedTokenStream
, losing span information.This PR recursively invokes
nt_to_tokenstream
on nestedTokenKind::Interpolated
tokens, effectively flattening the stream into a sequence of non-interpolated tokens. This allows it to compare equal with the re-parsed stream, allowing us to keep the original capturedTokenStream
(with span information).This requires all of the
probably_equal_for_proc_macro
methods to be moved fromlibrustc_ast
tolibrustc_parse
so that they can callnt_to_tokenstream
.