Compute a better lint_node_id during expansion

[Aaron1011]

When we need to emit a lint at a macro invocation, we currently use the
NodeId of its parent definition (e.g. the enclosing function). This
means that any #[allow] / #[deny] attributes placed 'closer' to the
macro (e.g. on an enclosing block or statement) will have no effect.

This commit computes a better lint_node_id in InvocationCollector.
When we visit/flat_map an AST node, we assign it a NodeId (earlier
than we normally would), and store than NodeId in current
ExpansionData. When we collect a macro invocation, the current
lint_node_id gets cloned along with our ExpansionData, allowing it
to be used if we need to emit a lint later on.

This improves the handling of #[allow] / #[deny] for
SEMICOLON_IN_EXPRESSIONS_FROM_MACROS and some asm!-related lints.
The 'legacy derive helpers' lint retains its current behavior
(I've inlined the now-removed lint_node_id function), since
there isn't an ExpansionData readily available.

[rust-highfive]

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

r? @petrochenkov

[Aaron1011]

@petrochenkov: This PR is now ready for review

[petrochenkov]

There are about 30 NodeIds in AST, but assign_id! is used 19 times in this PR.
This means only someNodeIds can be assigned to lint_node_id.
I'm not sure which subset of NodeIds is used for linting in this PR, and which subset should be used.

I think it's enough to track IDs that can be immediate parents of macro invocations (with "macro invocations" including uses of macro attributes).

If we are considering attributes, then some interesting situations may arise.
For example, does this example produce a warning?

#[allow(deprecated)]
#[deprecated_macro_attribute_equivalent_to_cfg_false]
struct S;

Apparently it does, because struct S; disappears before getting a meaningful NodeId (the ID is assigned after expanding all macro attributes), so struct S; is not an immediate parent of the macro attribute invocation, the containing module/crate is.
(Anyway, this snippet probably needs to be added as a test case.)

(I'll check which nodes can be immediate parents of macro invocations tomorrow.)

[petrochenkov]

I think it's enough to track IDs that can be immediate parents of macro invocations

Looks like I was wrong, pretty much anything with a NodeId can be an immediate parent of a macro invocation (including stuff like path segments - seg<ty!()>, and excluding only the most basic nodes like lifetimes).

However, it's not necessary to track them all, we only need to track parent nodes (not necessarily immediate) supporting attributes like #[allow], i.e. only nodes listed in Annotatable (that's only 13 assign_id!s), tracking with higher granularity won't have any effect.

[Aaron1011]

@petrochenkov: I've added the #[allow(deprecated)] test case, and removed the unnecessary assign_id! calls. See my reply to your comment about the handling of Stmt

[petrochenkov]

@bors r+

[bors]

📌 Commit cb862d5cac071a21735886dac9878ffb4562ae9f has been approved by petrochenkov

[bors]

☔ The latest upstream changes (presumably #86676) made this pull request unmergeable. Please resolve the merge conflicts.

[Aaron1011]

@bors r=petrochenkov

[bors]

📌 Commit 1c1c794 has been approved by petrochenkov

[bors]

⌛ Testing commit 1c1c794 with merge 9cc5500d72f84850fbde80fdf5520e2c97c1626d...

[bors]

💥 Test timed out

[Aaron1011]

@bors retry

[rust-log-analyzer]

A job failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

⌛ Testing commit 1c1c794 with merge 0ecff8c...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 0ecff8c to master...