Disallow cfg attribute (maybe others) on generic parameters
#51279
Labels
A-attributes
Area: Attributes (`#[…]`, `#![…]`)
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
kennytm
added
A-attributes
|
cc #48848 Context of why it should be disallowed: https://botbot.me/mozilla/rust-lang/2018-06-01/?msg=100694737&page=1 |
kennytm
added a commit
to kennytm/rust
that referenced
this issue
Jun 7, 2018
…ng-song-and-dance, r=nikomatsakis Deny #[cfg] and #[cfg_attr] on generic parameters. Fix rust-lang#51279. Attributes on generic parameters are not expanded, meaning `#[cfg]`, `#[cfg_attr]` and attribute proc macros are entirely ignored on them. This PR makes using the first two attributes an error, because if they are correctly expanded will affect the AST and change code behavior. I'm beta-nominating this, because generic parameter attributes are stabilizing in 1.27, and if we did not reserve their usage, we may never be able to repurpose the meaning of these attributes in the Rust 2015 edition.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As of 1.27, it is legal to put attributes on generic parameters. E.g.
fn foo<#[allow(dead_code)] T>(_t: T){}, although none of the current attributes do anything. This includes attributes we may want to use in the future, such ascfg. To avoid doing the warning song and dance we did with#[must_use]on functions, we should disallow them before the feature actually stabilizes.The text was updated successfully, but these errors were encountered: