mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-02 15:32:06 +00:00
fe72845f7b
Fix unused attributes on macro_rules. The `unused_attributes` lint wasn't firing on attributes of `macro_rules` definitions. The consequence is that many attributes are silently ignored on `macro_rules`. The reason is that `unused_attributes` is a late-lint pass, and only has access to the HIR, which does not have macro_rules definitions. My solution here is to change `non_exported_macro_attrs` to be `macro_attrs` (a list of all attributes used for `macro_rules`, instead of just those for `macro_export`), and then to check this list in the `unused_attributes` lint. There are a number of alternate approaches, but this seemed the most reliable and least invasive. I am open to completely different approaches, though. One concern is that I don't fully understand the implications of extending `non_exported_macro_attrs` to include non-exported macros. That list was originally added in #62042 to handle stability attributes, so I suspect it was just an optimization since that was all that was needed. It was later extended to be included in SVH in #83901. #80641 also added a use to check for `invalid` attributes, which seems a little odd to me (it didn't validate non-exported macros, and seems highly specific). Overall, there doesn't seem to be a clear story of when `unused_attributes` should be used versus an error like E0518. I considered alternatively using an "allow list" of built-in attributes that can be used on macro_rules (allow, warn, deny, forbid, cfg, cfg_attr, macro_export, deprecated, doc), but I feel like that could be a pain to maintain. Some built-in attributes already present hard-errors when used with macro_rules. These are each hard-coded in various places: - `derive` - `test` and `bench` - `proc_macro` and `proc_macro_derive` - `inline` - `global_allocator` The primary motivation is that I sometimes see people use `#[macro_use]` in front of `macro_rules`, which indicates there is some confusion out there (evident that there was even a case of it in rustc). |
||
---|---|---|
.. | ||
src | ||
Cargo.toml | ||
README.md |
rustc_target
contains some very low-level details that are
specific to different compilation targets and so forth.
For more information about how rustc works, see the rustc dev guide.