`$crate` -> `$ident:ident` -> `identity_proc_macro!($ident)` panics in the proc macro

[rodrimati1992]

Code

I tried cargo test-ing this proc macro crate:

/// ```rust
/// pub extern crate proc_macro_crate;
/// 
/// #[macro_export]
/// macro_rules! foo {
///     ($($path:ident)::*) => (
///         $crate::proc_macro_crate::identity!{
///             $($path)::*
///         }
///     )
/// }
/// 
/// #[macro_export]
/// macro_rules! baz {
///     () => (
///         $crate::foo!($crate::BAR)
///     )
/// }
/// 
/// pub const BAR: u32 = 19;
/// 
/// fn main(){ 
///     println!("{}", crate::baz!());
/// }
/// 
/// ```
#[proc_macro]
pub fn identity(input: proc_macro::TokenStream) -> proc_macro::TokenStream {
    input.into_iter().collect()
}

I expected to see this happen: The test completes successfully

Instead, this happened:
The test fails compilation with this error:

error: proc macro panicked
  --> src/lib.rs:7:9
   |
7  | /         $crate::proc_macro_crate::identity!{
8  | |             $($path)::*
9  | |         }
   | |_________^
...
23 |       println!("{}", crate::baz!());
   |                      ------------- in this macro invocation
   |
   = help: message: `"$crate"` is not a valid identifier
   = note: this error originates in the macro `$crate::foo` (in Nightly builds, run with -Z macro-backtrace for more info)

Version it worked on

It most recently worked on:

rustc 1.60.0 (7737e0b5c 2022-04-04)
binary: rustc
commit-hash: 7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c
commit-date: 2022-04-04
host: x86_64-unknown-linux-gnu
release: 1.60.0
LLVM version: 14.0.0

Version with regression

rustc --version --verbose:

rustc 1.61.0 (fe5b13d68 2022-05-18)
binary: rustc
commit-hash: fe5b13d681f25ee6474be29d748c65adcd91f69e
commit-date: 2022-05-18
host: x86_64-unknown-linux-gnu
release: 1.61.0
LLVM version: 14.0.0

This also fails in 1.62 and 1.63.

Meta

This appears to be fixed in the beta channel, but I could not find a mention of this bug or a related one.

It's entirely possible that the bug will trigger again in future versions if this code isn't used in tests.

[steffahn]

Bisection shows it regressed in #92472 and got fixed in #98189. Looks like this issue wasn’t deliberately fixed, since #98189 doesn’t call out any issue being fixed. Also #92472 did involve minor breakage, as discussed in its thread, but I haven’t looked into it enough to tell whether those cases of breakage were similar to this issue or different.

[steffahn]

@rustbot label A-macros, A-proc-macros

[steffahn]

cc @petrochenkov (author of #92472) and @mystor (author of #98189)

(read #101211 (comment) above to see how these PRs are relevant)

[mystor]

Looking at the code changes from #92472 it makes sense that this regressed, as the call to Ident::new (https://github.com/rust-lang/rust/pull/92472/files#diff-002b2429c67f4267af1485b8b9e2f95cbfe586971ed97f832da4d4d45d0e1e41R179) would have done a check and rejected creating $crate. The code (which was originally introduced in #73084: https://github.com/rust-lang/rust/pull/73084/files#diff-75938b59f6567a18bc15d178cf794cbb3c7e2c846b2afcdfd56110824c70ed07R179), should've probably avoided the Ident::new constructor from the get-go, but it wasn't an issue because $crate wasn't a possible identifier in that case previously.

In #98189, I changed the logic there to avoid going through that constructor when re-building the tokens internally, so we don't do the broken validation on that side anymore, and the problem wouldn't happen anymore.

I don't think there's much more to be done here, as it's fixed already on beta, and isn't likely to regress with the new design.

[steffahn]

I don't think there's much more to be done here, as it's fixed already on beta, and isn't likely to regress with the new design.

Thanks a lot for your insights!

[steffahn]

@rustbot label E-easy. (We only need a test to close this issue.)