Fix span of unsafe attribute diagnostic

[ehuss]

This fixes the span of the unsafe_attr_outside_unsafe diagnostic when the attribute uses cfg_attr and comes from a macro. Previously the span it was pointing to was in the wrong place (offset by 2 bytes in the start, and 1 byte in the end), causing a corrupt suggestion.

The problem is that the lint was trying to do manual byte manipulation of the Attribute span to get within the #[ and ] tokens. However, when the attribute comes from cfg_attr, that span starts from the attribute path (like no_mangle), not the #[ of the cfg_attr.

The solution here is to store the span of the AttrItem while parsing, so that we know for sure that it covers the correct range (the path and all args). We could not use AttrItem::span() (which is removed in this PR), because that function did not correctly account for the path and arguments coming from separate expansion contexts. For example, in the macro expansion of #[$p = $a], the span would be $p = because you are not allowed to generate a span across expansion contexts.

Fixes #132908

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[compiler-errors]

Are you sure we can't save this by using one of the span ancestor functions like https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/span_encoding/struct.Span.html#method.find_ancestor_in_same_ctxt?

[petrochenkov]

This is another instance of the span combining problem really.
The x.to(y) operation should just work for things like #[$a = $b] if all metavar spans are recorded.
In fact the parser does exactly the same a.to(b) operation to save the span into the AST, it just may see different spans if nonterminals are involved.

The logic in validate_attrs may work or not work depending on how exactly parts of the attribute was passed (as tt, ident, meta or expr), previously it was fine-tuned for one scenarios, now it's fine tuned for others.

The only certain thing here is that the manual span arithmetic (+/- BytePos(1/2)) should not be performed.

[petrochenkov]

Maybe just remove the span arithmetic and not try to improve spans for macro scenarios?

[ehuss]

I don't see a way to get find_ancestor_in_same_ctxt to work. The issue is that in the case of #[link_section = $s], the span for $s is not stored anywhere. The AttrItem stores the path as link_section (or $e in the other example, it is before expansion). The AttrArgs stores the eq_span for the = in the macro, and the value as "foo" from the invocation.

I think supporting proper suggestions in macros is pretty important, as this pattern comes up quite frequently. I realize this can only be tuned to support certain scenarios, and not be perfect in all situations. However, I think recording the span as implemented in this PR covers the vast majority of situations well.

Are you still concerned with the regressions here?

[petrochenkov]

Increasing the size of AttrItem may be a performance sensitive change.

[petrochenkov]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 92fe744 with merge 46c9e3a...

[bors]

☀️ Try build successful - checks-actions
Build commit: 46c9e3a (46c9e3a092ea03e1b0a4f75f57a4c0997f490346)

[rust-timer]

Finished benchmarking commit (46c9e3a): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.2%, 0.4%]	5
Regressions ❌ (secondary)	0.3%	[0.2%, 0.3%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.2%, 0.4%]	5

Max RSS (memory usage)

Results (primary 2.1%, secondary 1.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.1%	[1.2%, 3.0%]	2
Regressions ❌ (secondary)	1.5%	[1.5%, 1.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[1.2%, 3.0%]	2

Cycles

Results (secondary -2.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.4%, -2.0%]	3
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.2%, secondary 0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.0%, 0.7%]	49
Regressions ❌ (secondary)	0.2%	[0.1%, 0.6%]	18
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.0%, 0.7%]	49

Bootstrap: 796.689s -> 796.521s (-0.02%)
Artifact size: 335.98 MiB -> 336.01 MiB (0.01%)

[compiler-errors]

I believe the correct fix for this is #134478