Repository navigation
Fix/clarify inert/active attributes, and attribute sequence. #565
Description
The inert/active attribute description is not be correct. The following comment needs to be incorporated: #537 (review)
However, I think the inert/active distinction is subtle and should have more clarification. It is possible to "see" an active attribute based on the point in time during compilation (for example, an attribute macro placed before #[test] sees the test attribute, it has not been removed, yet).
Also, to me it seems like like cfg and cfg_attr aren't always active. If the predicate is true, they are clearly visible from attribute macros, so they have not been removed. This comment implies that things are broken.
I would like to know how I can validate this inert/active distinction by reading the rustc code. It is not tracked in any data structure I can see, and I do not know through which mechanism an attribute removes itself. Otherwise I feel like I am shooting in the dark trying to document this.
Also I think the order that attributes are processed and when attributes remove themselves should be documented. For example, do attribute macros see derive macros (yes, the derive has not been removed, yet). What is the significance of the order that attributes are listed? (Presumably they are processed top-down?) Attribute macros seem to be removed only after they are processed (an attribute macro sees the attributes below it, but not above it). When is cfg pruning done (pretty early)? In general I think the order attributes are processed and when attributes remove themselves should be documented.
Activity
petrochenkov commentedon Apr 21, 2019
If the attribute resolves to
Def::Macro, then it's active.If the attribute resolves to
Def::NonMacroAttr, then it's inert.Built-in attributes bypass resolution (kind of, only the initial pass, but not the validation pass) and they are all inert, unless they are explicitly expanded by special code in libsyntax like
cfg,cfg_attrandderive.Through generic macro expansion machinery usually.
Through hacks for
cfg,cfg_attrandderive.The general intent is to expand everything in straightforward left-to-right fashion (except for
cfg/cfg_attr):basically.
Derives currently have some issues in this area due to their chaotic Macro 1.1 and legacy nature, but they should be realistically fixable without noticeable breakage.
petrochenkov commentedon Feb 13, 2021
After rust-lang/rust#79078
deriveis a regular proc macro attribute without any special properties with regards to expansion order.ehuss commentedon Jul 1, 2025
#1879 added the rule
cfg.cfg_attr.duplicateswhich is pretty vague right now, and should probably be updated once we add documentation on the order that things are processed.