Remove NormalAttr#159221
Conversation
By inlining `AttrItem` into `NormalAttr` and then renaming the result `AttrItem` (because `AttrItem` is a better and more widely-used name than `NormalAttr`). This is a very mechanical change, except for the following. - In `expand_cfg_attr_item`, where the commit adds some comments explaining the token usage and adds an assertion, in order to clarify existing behaviour. - An expanded comment on `AttrItem`. - An expanded comment on `ParseNtResult`.
|
cc @rust-lang/rustfmt The parser was modified, potentially altering the grammar of (stable) Rust cc @fmease
cc @rust-lang/clippy Some changes occurred in compiler/rustc_attr_parsing cc @jdonszelmann, @JonathanBrouwer Some changes occurred in compiler/rustc_builtin_macros/src/autodiff.rs cc @ZuseZ4 |
| pub args: AttrItemKind, | ||
| // Tokens for the full attribute, e.g. `#[foo]`, `#![bar]`. (Compare this with | ||
| // `ParseNtResult::Meta`; `expand_cfg_attr_item` is where the two cases interact.) | ||
| pub tokens: Option<LazyAttrTokenStream>, |
There was a problem hiding this comment.
I don't think much changed here since #158942, these tokens still do not belong to the AttrItem.
Putting them here removes one type, but instead introduces confusion, IMO.
Semantically the tokens belong to the Attribute level, they were moved to the AttrKind::Normal level only as an optimization for doc comments. Moving them into AttrItem goes even further from the right mental model.
Normal(Box<AttrItem>, Option<LazyAttrTokenStream>)would be fine semantically, but too large (?).Normal(Box<(AttrItem, Option<LazyAttrTokenStream>)>)would be fine semantically too, and avoids the size issue, but aNormalAttrstruct with named fields is probably still better than a tuple.
|
☔ The latest upstream changes (presumably #159213) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
After #158942 it's no longer necessary. Details in individual commits.
r? @petrochenkov