Open ehuss opened 1 day ago
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
@bors try @rust-timer queue
Awaiting bors try build completion.
@rustbot label: +S-waiting-on-perf
:hourglass: Trying commit 92fe7447af3f1483195a562d4149e2f6931792d6 with merge 46c9e3a092ea03e1b0a4f75f57a4c0997f490346...
:sunny: Try build successful - checks-actions
Build commit: 46c9e3a092ea03e1b0a4f75f57a4c0997f490346 (46c9e3a092ea03e1b0a4f75f57a4c0997f490346
)
Queued 46c9e3a092ea03e1b0a4f75f57a4c0997f490346 with parent a7d9ebdf088f166e91759ec5b3b0625e3c1d0c82, future comparison URL. There is currently 1 preceding artifact in the queue. It will probably take at least ~2.2 hours until the benchmark run finishes.
This fixes the span of the
unsafe_attr_outside_unsafe
diagnostic when the attribute usescfg_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 fromcfg_attr
, that span starts from the attribute path (likeno_mangle
), not the#[
of thecfg_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 useAttrItem::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