-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Tracking Issue for built-in attribute macro #[cfg_eval]
#82679
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Implement built-in attribute macro `#[cfg_eval]` + some refactoring This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in rust-lang#79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes. The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input). The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items. `cfg_eval` was the first name suggested in rust-lang#79078, but other alternatives are also possible, e.g. `cfg_expand`. ```rust #[cfg_eval] #[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]` struct S { #[cfg(FALSE)] field: u8, } ``` Tracking issue: rust-lang#82679
Implement built-in attribute macro `#[cfg_eval]` + some refactoring This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in rust-lang#79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes. The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input). The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items. `cfg_eval` was the first name suggested in rust-lang#79078, but other alternatives are also possible, e.g. `cfg_expand`. ```rust #[cfg_eval] #[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]` struct S { #[cfg(FALSE)] field: u8, } ``` Tracking issue: rust-lang#82679
Implement built-in attribute macro `#[cfg_eval]` + some refactoring This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in rust-lang#79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes. The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input). The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items. `cfg_eval` was the first name suggested in rust-lang#79078, but other alternatives are also possible, e.g. `cfg_expand`. ```rust #[cfg_eval] #[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]` struct S { #[cfg(FALSE)] field: u8, } ``` Tracking issue: rust-lang#82679
Implement built-in attribute macro `#[cfg_eval]` + some refactoring This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in rust-lang#79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes. The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input). The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items. `cfg_eval` was the first name suggested in rust-lang#79078, but other alternatives are also possible, e.g. `cfg_expand`. ```rust #[cfg_eval] #[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]` struct S { #[cfg(FALSE)] field: u8, } ``` Tracking issue: rust-lang#82679
Implement built-in attribute macro `#[cfg_eval]` + some refactoring This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in rust-lang#79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes. The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input). The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items. `cfg_eval` was the first name suggested in rust-lang#79078, but other alternatives are also possible, e.g. `cfg_expand`. ```rust #[cfg_eval] #[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]` struct S { #[cfg(FALSE)] field: u8, } ``` Tracking issue: rust-lang#82679
It looks like #![feature(custom_inner_attributes)]
#![feature(cfg_eval)]
#![feature(stmt_expr_attributes)]
fn main() {
let a = #[cfg_attr(FALSE, rustc_dummy)] {
#![cfg_eval]
};
} Is this intentional? |
@Aaron1011 |
I had thought that allowing it as inner attribute would interfere with token collection optimizations, but it turned out to be straightforward to deal with. |
Hello! |
The previous stabilization attempt - #87221. |
Feature gate:
#![feature(cfg_eval)]
This is a tracking issue for built-in attribute macro
#[cfg_eval]
that is used for eagerly expanding all#[cfg]
and#[cfg_attr]
attributes in its input ("fully configuring" the input).The effect is identical to effect of
#[derive(Foo, Bar)]
which also fully configures its input before passing it to macrosFoo
andBar
.Public API
Steps / History
#[cfg_eval]
+ some refactoring #82682Unresolved Questions
The text was updated successfully, but these errors were encountered: