Fix inconsistencies in handling of inert attributes on statements

[Aaron1011]

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.

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.

The unused_doc_comments lint now fires on a number of items in the
stnadard library. I've added #[allow(unused_doc_comments)] to these
items.

[rust-highfive]

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

This lint is firing on a large number of doc comments within the compiler itself. I see several different ways of proceeding:

1. Convert all of these doc comments to regular comments
2. Add a blanket #![allow(unused_doc_comments)] to compiler crates.
3. Add #[allow(unused_doc_comments)] on a case-by-case basis.
4. Decide that we don't actually want unused_doc_comments to apply to these cases.

cc @rust-lang/rustdoc Is there any reason to have doc comments (as a opposed to regular comments) on a function if it won't be rendered by rustdoc?

[jyn514]

cc rust-lang/rustdoc Is there any reason to have doc comments (as a opposed to regular comments) on a function if it won't be rendered by rustdoc?

@Aaron1011 not that I'm aware of. IMO they should be changed to regular comments (1), but I don't feel very strongly about that.

[Mark-Simulacrum]

Nominating for lang team, I suspect we'll want to just let this go through (it's not really breaking) but it's an interesting question of whether these documentation comments are truly unused.

[Aaron1011]

The 'inner items' message was introduced here: https://github.com/rust-lang/rust/pull/57882/files#diff-38d78212bad0cf87e09d707ee7331a84a049fac2d8b1c7b26584580be81d818aR860-R868

So, it looks like the intention of PR #57882 was to lint doc comments on statement items - this just never worked until now.

[petrochenkov]

r=me on the implementation.

[Aaron1011]

I'm going to split out the purely internal changes into a separate PR, with unused_doc_comments explicitly disabled on item statements. This will preserve the current behavior of unused_doc_comments, unblock #78296, and allow the lang team to discuss the behavior of unused_doc_comments.

[Aaron1011]

@petrochenkov: I've moved the implementation to #78326

[Aaron1011]

The internal rustc changes were merged in #78326. Closing in favor of #78367