-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-attributesArea: Attributes (`#[…]`, `#![…]`)Area: Attributes (`#[…]`, `#![…]`)A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)A-syntaxextArea: Syntax extensionsArea: Syntax extensionsC-bugCategory: This is a bug.Category: This is a bug.P-highHigh priorityHigh priorityT-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.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Description
E.g. this successfully compiles on stable 1.19 / beta 1.20 /nightly
#![allow(unused)]
macro_rules! m {
($attr_path: path) => {
#[$attr_path]
fn f() {}
}
}
m!(inline<'nonexistent_lifetime, u8, NonExistentType>);
fn main() {}
There are too many kinds of attributes - built in, custom, derives, legacy derives, procedural macros, legacy procedural macros, maybe something else - I'm not sure which of them are affected. Many of these attributes are removed from AST during expansion, so simply adding a check into AST validation pass won't be enough, the checking needs to be done during expansion, like for macro paths (
rust/src/librustc_resolve/macros.rs
Line 391 in 3cf2c04
let msg = format!("type parameters are not allowed on {}s", kind); |
cc @jseyfried
Metadata
Metadata
Assignees
Labels
A-attributesArea: Attributes (`#[…]`, `#![…]`)Area: Attributes (`#[…]`, `#![…]`)A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)A-syntaxextArea: Syntax extensionsArea: Syntax extensionsC-bugCategory: This is a bug.Category: This is a bug.P-highHigh priorityHigh priorityT-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.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.