Manually fulfill lint expectations for all unsafe blocks with metavars

[y21]

Fixes #14488

Context: the macro_metavars_in_unsafe lint looks for unsafe blocks with a macro span that then contain expressions with a root context span (which means that it is a macro with an unsafe block expanding a metavariable inside). In order to avoid emitting a warning for every single macro invocation, it will deduplicate the unsafe blocks by the span in the macro.

This leads to the linked issue where because of the deduplicating and removing unsafe blocks that all belong to the same unsafe block in the macro, only one of the unsafe blocks will actually have its lint expectation fulfilled. This PR fixes that by manually fulfilling all of the unsafe blocks from all expansions before deduplicating them.

changelog: [macro_metavars_in_unsafe]: fix unfulfilled #[expect] if macro is invoked multiple times

[rustbot]

r? @blyxyas

rustbot has assigned @blyxyas.
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

[samueltardieu]

Neat

[blyxyas]

Wouldn't this also affect to any lint that apply to macros? I'm not sure if there are more, but it may add more value to modify behaviour upstream?

For now, as I think there aren't any other lints affecting to macro_rules! declarations, we can accept this, but if other lints start to lint in macros, we may be interested in fixing this in the expectation lint behaviour handler in upstream.

[y21]

I don't know if there's a way this could be generalized upstream. IMO it's correct from the compiler's perspective, they are all their own expressions with unique HirIds and their own #[expect] so it's correct that all of the expression HirIds should have their expectation fulfilled.

It's an issue very specific to this lint if it decides to explicitly filter some out and not emit on them imo. I don't think there is any other lint like this, where we really want to look at macro definitions specifically, but because that isn't possible (AST for macro definitions is a raw, untyped TokenStream that we can't really analyze for unsafe blocks like this), it will instead look at macro expansions of local macros and then pretend that it lints a macro definition by deduplicating the unsafe blocks so the user only gets one warning for that unsafe block in the macro.

It's kind of a hack that I don't think is worth trying to generalize. It also doesn't really work all that well because this lint only works if the macro is actually invoked at least once in the same crate.
I also remember seeing discussions on zulip that we probably shouldn't have more lints for macro_rules! precisely because it needs some ugly hacks, so. IMO not worth

[blyxyas]

LGTM, thanks! ❤️
What an interesting lint.