-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Re-land PR #72388: Recursively expand TokenKind::Interpolated
in probably_equal_for_proc_macro
#73084
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Re-land PR #72388: Recursively expand TokenKind::Interpolated
in probably_equal_for_proc_macro
#73084
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
Let's a try build for a Crater run, so that we can verify that no new crates are broken by this change: @bors try |
⌛ Trying commit e2242b8217ed26f58df0d9adf30de04c61d1a2f4 with merge 9be3f2265fdeef8522c7f7b149329a178eac5317... |
This comment has been minimized.
This comment has been minimized.
@bors try |
⌛ Trying commit 6329f808c468086795b6d2cc14f439f172907393 with merge 879b8cb7dc2ad9102994457e73cf78d124926ea5... |
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-azure |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Marking as waiting on author to triage the regressions. |
A large chunk of the regressions seems to be from crates still using an outdated Unfortunately, many of the regressions are legitimate. It looks like the |
The method `Span.join` will return `None` if the start and end `Span`s are from different files. This is currently difficult to observe in practice due to rust-lang/rust#43081, which causes span information (including file information) to be lost in many cases. However, PR rust-lang/rust#73084 will cause `Spans` to be properly preserved in many more cases. This will cause `rocket` to to stop compiling, as this code will end up getting hit with spans from different files (one from rocket, and one from the `result` ident defined in the `pear_try!` macro. To reproduce the issue: 1. Checkout SergioBenitez/Rocket#63a4ae048540a6232c3c7c186e9d027081940382 2. Install https://github.com/kennytm/rustup-toolchain-install-master if you don't already have it 3. Run `rustup-toolchain-install-master 879b8cb7dc2ad9102994457e73cf78d124926ea5` (this corresponds to the latest commit from rust-lang/rust#73084) 4. From the `Rocket` checkout, run `cargo +879b8cb7dc2ad9102994457e73cf78d124926ea5 build` 5. Observe the panic from `Pear` I've based this PR on the commit for `Pear 0.1.2`, since the master branch has many breaking changes. I would recommend merging this change into a separate branch, and making a new `0.1.3` point release.
In `struct-opt-derive`, a function is generated with a parameter named `matches`. Since `quote!` is used to generate the function, the `matches` token will be resolved using `Span::call_site`. However, the literal identifier `matches` is also used inside several `quote_spanned!` expressions. Such a `matches` identifier will be resolved using the `Span` passed to `quote_spanned!`, which may not be the same as `Span::call_site`. Currently, this is difficult to observe in practice, due to rust-lang/rust#43081 . However, once PR rust-lang/rust#73084 is merged, proc macros will see properly spanned tokens in more cases, which will cause these incorrect uses of `quote_spanned!` to break. This PR uses `quote! { matches }` to generate a correctly spanned `matches` token, which is then include in the `quote_spanned!` expressions using `#matches`.
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
This updates parity-scale-codec{-derive} to prepare for a rustc release that would otherwise break the derive implementation: rust-lang/rust#73084
PR #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 #72545 and #72622). These regressions fell into two categoriesGroup
s withDelimiter::None
, which are inserted duringmacro_rules!
expansion (but are lost during stringification and re-parsing). A large number of these regressions were due tosyn
andproc-macro-hack
, but several crates needed changes to their own proc-macro code.quote_spanned!
). However, two crates had intentionally written unhygenicmacro_rules!
macros, which were able to access identifiers that were not passed as arguments (see Crater run for PR #72388 - Recursively expandTokenKind::Interpolated
inprobably_equal_for_proc_macro
#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 #72545 (comment), not re-landing PR #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 unhygenicmacro_rules!
macros in the time it takes that PR to be merged.