Bad suggestion for macro_rules macros generated from a proc-macro

[ehuss]

In a proc-macro that generates a macro_rules macro that triggers lints like unsafe_op_in_unsafe_fn, or unsafe_attr_outside_unsafe, the suggestion ends up suggesting that the unsafe should go around the attribute, which is invalid syntax.

// proc-macro `pm`
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn pm(_attr: TokenStream, _item: TokenStream) -> TokenStream {
    "macro_rules! foo {
        () => {pub unsafe fn foo() { let _ = std::mem::zeroed::<i32>(); } };
    }"
    .parse()
    .unwrap()
}

#![warn(unsafe_op_in_unsafe_fn)]

#[pm::pm]
struct S;

foo! {}

Gives a suggestion that ends up being:

{ unsafe #[pm::pm]}

which is invalid syntax.

Seen with the vtable crate.

This is a bit of curious case, as I would have expected the tokens of the macro_rules definition to be 2021 edition, and that the tokens it in turns generates also be 2021. Offhand I don't know how macro_rules determine which edition the tokens it emits should be (I'm guessing it is using the edition of the local crate, instead of the edition of the generated macro_rules definition).

Meta

rustc --version --verbose:

rustc 1.84.0-nightly (143ce0920 2024-11-10)
binary: rustc
commit-hash: 143ce0920a2307b19831160a01f06f107610f1b2
commit-date: 2024-11-10
host: aarch64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.3

[compiler-errors]

For the record, the macro_rules that is generated will be spanned using the edition of the callsite, so it'll be edition 2024 even if the proc macro is edition 2021.

https://github.com/rust-lang/rust/blob/master/compiler/rustc_expand/src/proc_macro_server.rs#L550

[traviscross]

cc @eholk @vincenzopalazzo

[ehuss]

I'm wondering if the switch of edition is happening here, where it uses the session edition to compile the macro, instead of the edition where the macro was defined.

[traviscross]

Another test case, which is a bit different in that it's testing in which edition the macro fragment specifiers are evaluated:

// In the proc macro crate:

//@ edition: 2021
extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn pm(_attr: TokenStream, _item: TokenStream) -> TokenStream {
    r#"macro_rules! edition {
    ($_:expr) => {
        println!("Rust 2024")
    };
    (const {}) => {
        println!("Rust 2021")
    };
}
"#
    .parse()
    .unwrap()
}

// In another crate:

//@ edition: 2024
use macros_proc::pm;

#[macros_proc::pm]
struct S;

fn main() {
    edition!(const {});
}

This prints "Rust 2021".

[traviscross]

Here's another test case:

// In the proc macro crate:

//@ edition: 2021
extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn pm(_attr: TokenStream, _item: TokenStream) -> TokenStream {
    r#"macro_rules! edition {
        ($d:tt) => { macro_rules! edition_inner {
            ($d_:expr) => {
                println!("Rust 2024")
            };
            (const {}) => {
                println!("Rust 2021")
            };
        }};
    }
"#
    .parse()
    .unwrap()
}

// In another crate:

//@ edition: 2024
use macros_proc::pm;

#[macros_proc::pm]
struct S;

fn main() {
    edition!($);
    edition_inner!(const {});
}

This prints "Rust 2024".

[ehuss]

I posted a partial fix in #133274. That fixes the problem that a 2024 crate would error when using a proc-macro from an older edition that emits a macro_rules macro.

I still don't know how to fix the lint firing in 2021 in that same situation. Somehow there should be a way for the lint to recognize that the place it is adding a suggestion to is not correct, and that it doesn't need to fire at all...