diff options
| author | bors <bors@rust-lang.org> | 2021-05-16 20:19:45 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2021-05-16 20:19:45 +0000 |
| commit | fe72845f7bb6a77b9e671e6a4f32fe714962cec4 (patch) | |
| tree | e4b4419ed788537aec0fef7c1bd1a0f6e018bc2c /compiler/rustc_target | |
| parent | 7dc9ff5c629753b6930ecfe9a0446538b8e25fb7 (diff) | |
| parent | 5bbc240ffbb0dcf510fd73d71dae529bd345e6b2 (diff) | |
| download | rust-fe72845f7bb6a77b9e671e6a4f32fe714962cec4.tar.gz rust-fe72845f7bb6a77b9e671e6a4f32fe714962cec4.zip | |
Auto merge of #85312 - ehuss:macro_use-unused-attr, r=petrochenkov
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).
Diffstat (limited to 'compiler/rustc_target')
| -rw-r--r-- | compiler/rustc_target/src/asm/mod.rs | 3 |
1 files changed, 0 insertions, 3 deletions
diff --git a/compiler/rustc_target/src/asm/mod.rs b/compiler/rustc_target/src/asm/mod.rs index c2f6bb76295..c17c2961434 100644 --- a/compiler/rustc_target/src/asm/mod.rs +++ b/compiler/rustc_target/src/asm/mod.rs @@ -6,7 +6,6 @@ use rustc_span::Symbol; use std::fmt; use std::str::FromStr; -#[macro_use] macro_rules! def_reg_class { ($arch:ident $arch_regclass:ident { $( @@ -51,7 +50,6 @@ macro_rules! def_reg_class { } } -#[macro_use] macro_rules! def_regs { ($arch:ident $arch_reg:ident $arch_regclass:ident { $( @@ -129,7 +127,6 @@ macro_rules! def_regs { } } -#[macro_use] macro_rules! types { ( $(_ : $($ty:expr),+;)? |
