-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Open
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-edition-2024Area: The 2024 editionArea: The 2024 editionA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.A-suggestion-diagnosticsArea: Suggestions generated by the compiler applied by `cargo fix`Area: Suggestions generated by the compiler applied by `cargo fix`C-bugCategory: This is a bug.Category: This is a bug.D-editionDiagnostics: An error or lint that should account for edition differences.Diagnostics: An error or lint that should account for edition differences.D-invalid-suggestionDiagnostics: A structured suggestion resulting in incorrect code.Diagnostics: A structured suggestion resulting in incorrect code.I-edition-triagedIssue: This issue has been reviewed and triaged by the Edition team.Issue: This issue has been reviewed and triaged by the Edition team.L-unsafe_op_in_unsafe_fnLint: unsafe_op_in_unsafe_fnLint: unsafe_op_in_unsafe_fnT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
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
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-edition-2024Area: The 2024 editionArea: The 2024 editionA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.A-suggestion-diagnosticsArea: Suggestions generated by the compiler applied by `cargo fix`Area: Suggestions generated by the compiler applied by `cargo fix`C-bugCategory: This is a bug.Category: This is a bug.D-editionDiagnostics: An error or lint that should account for edition differences.Diagnostics: An error or lint that should account for edition differences.D-invalid-suggestionDiagnostics: A structured suggestion resulting in incorrect code.Diagnostics: A structured suggestion resulting in incorrect code.I-edition-triagedIssue: This issue has been reviewed and triaged by the Edition team.Issue: This issue has been reviewed and triaged by the Edition team.L-unsafe_op_in_unsafe_fnLint: unsafe_op_in_unsafe_fnLint: unsafe_op_in_unsafe_fnT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.