Fix ICE from cfg_attr_trace

[chenyukang]

Fixes #154801

r? @JonathanBrouwer

The root cause is we recovery from parsing attribute error here:

rust/compiler/rustc_attr_parsing/src/parser.rs

Line 550 in ed6f9af

err.cancel();

while the later suggestion code from type checking try to inspect the attr span of the expr in the second error, keep the span seems reasonable.

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[JonathanBrouwer]

How does this behave with multiple cfg_attr attributes? Since this attribute can exist multiple times, ideally we should have a ThinVec<Span> here?

[JonathanBrouwer]

This issue is not specific to cfg_attr, this will ICE with all attributes.
For example, this also ICES:

fn main() {
    let _x = 30;
    #[inline]
    _x
}

I think @jdonszelmann had an idea involving MultiSpans at some point to properly fix this

[chenyukang]

I updated the code.

The reason is that Attribute::Parsed(AttributeKind::...) does not seem to have a uniform “source span” model, a lot of them don't have span.

The current callers of has_span_without_desugaring_kind only need the narrower diagnostics question: whether an attribute should make suggestion rendering treat the expression like a prefixed form. I think a proper name is is_prefix_attr_for_suggestions: the goal is to reflect that this is not really a generic span-recovery API.

The new fix's behavior is intentionally conservative. We still filter out desugaring-generated lint attributes precisely where we can identify them, but otherwise prefer treating parsed expression attributes as affecting suggestion precedence.

a more concrete way is maybe add a API such as get_span_from_attr(attr_kind) -> Vec<Span> and then check desugaring_kind of spans, I'm hesitant whether it's necessary.