Split out statement attributes changes from #78306 #78326
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.
```rust
trait Foo {
#[allow(unused_attributes)] #[inline] fn first();
#[inline] #[allow(unused_attributes)] fn second();
}
```
However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).
Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.
This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:
* The `HasAttr` impl for `StmtKind` now returns attributes for
`StmtKind::Item`, treating it just like every other `StmtKind`
variant. The only place relying on the old behavior was macro
which has been updated to explicitly ignore attributes on item
statements. This allows the `unused_doc_comments` lint to fire for
item statements.
* The `early` and `late` lint visitors now activate lint attributes when
invoking the callback for `Stmt`. This ensures that a lint
attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
sibiling attributes on an item statement.
For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR rust-lang#78306
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit ac384ac has been approved by |
bors
added
S-waiting-on-bors
jyn514
added
A-attributes
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 25, 2020
Rollup of 8 pull requests Successful merges: - rust-lang#77984 (Compute proper module parent during resolution) - rust-lang#78085 (MIR validation should check `SwitchInt` values are valid for the type) - rust-lang#78208 (replace `#[allow_internal_unstable]` with `#[rustc_allow_const_fn_unstable]` for `const fn`s) - rust-lang#78209 (Update `compiler_builtins` to 0.1.36) - rust-lang#78276 (Bump backtrace-rs to enable Mach-O support on iOS.) - rust-lang#78320 (Link to cargo's `build-std` feature instead of `xargo` in custom target docs) - rust-lang#78322 (BTreeMap: stop mistaking node::MIN_LEN for a node level constraint) - rust-lang#78326 (Split out statement attributes changes from rust-lang#78306) Failed merges: r? `@ghost`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the same as PR #78306, but
unused_doc_commentsis modified to explicitly ignore statement items (which preserves the current behavior).This shouldn't have any user-visible effects, so it can be landed without lang team discussion.
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g.
#[allow]) that apply to it.This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an
unused_attributesfor#[inline], since the sibiling#[allow(unused_attributes)]suppressedthe warning.
However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside
StmtKind(e.g.
Item).Currently, this is difficult to observe due to another issue - the
HasAttrsimpl forStmtKindignores attributes forStmtKind::Item.As a result, the
unused_doc_commentslint will never see attributes onitem statements.
This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:
HasAttrimpl forStmtKindnow returns attributes forStmtKind::Item, treating it just like every otherStmtKindvariant. The only place relying on the old behavior was macro
which has been updated to explicitly ignore attributes on item
statements. This allows the
unused_doc_commentslint to fire foritem statements.
earlyandlatelint visitors now activate lint attributes wheninvoking the callback for
Stmt. This ensures that a lintattribute (e.g.
#[allow(unused_doc_comments)]) can be applied tosibiling attributes on an item statement.
For now, the
unused_doc_commentslint is explicitly disabled on itemstatements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306