Always invoke statement attributes on the statement itself

[Aaron1011]

This is preparation for PR #78296, which will require us to handle
statement items in addition to normal items.

[rust-highfive]

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

In #78296 (comment) I meant including the rustc_expand changes (and therefore rustc_ast changes as well.)

I've left the tests in this PR since they otherwise produce no useful output (we get a parse error before the macros are invoked)

I think they should parse if the #[attr] $stmt bits are removed?
(I'm just interested in looking at the test diff that the parsing and token collection changes bring.)

[Aaron1011]

@petrochenkov: Splitting out just the rustc_expand changes without the token collection causes us to lose spans for attribute macros in item statements (e.g. fn foo() { #[my_attr] fn bar() {} }) - we now invoke #[my_attr] on a statement, but we still have the buggy statement token collection.

I could try to add a workaround, but it would be immediately reverted by #78296

[Aaron1011]

@petrochenkov: I've added the rustc_expand changes, together with modified versions of the tests. I needed to add a hack to preserve spans for the already-stable case of attributes on statement items, but it turned out to be a small change.

[Aaron1011]

This is the behavior that we want - the trailing semicolon is not considered part of the statement. I'll make sure that this behavior is preserved in #78296

[petrochenkov]

Splitting out just the rustc_expand changes without the token collection causes us to lose spans for attribute macros in item statements (e.g. fn foo() { #[my_attr] fn bar() {} }) - we now invoke #[my_attr] on a statement, but we still have the buggy statement token collection.

I see, I assumed that you could use tokens from the item (and looks like that's what the updated PR does).

[petrochenkov]

r=me with #79326 (comment) addressed.

[Aaron1011]

I updated the PR description to better reflect the changes

[Aaron1011]

@bors r=petrochenkov

[bors]

📌 Commit 9c9f406 has been approved by petrochenkov

[bors]

⌛ Testing commit 9c9f406 with merge 22f0c711908e699e465a9a34980861cbce4902dd...

[bors]

💔 Test failed - checks-actions

[Aaron1011]

Failed due an old version of procedural-masquerade being in use, which is too strict about checking the pretty-printed output. I'm not sure why this only started failing now.

We need to bump to a version of procedural-masquerade that includes servo/rust-cssparser#274

[Aaron1011]

@SimonSapin: It looks like cargotest is pulling in an old version of cssparser due to the servo dependency. What's the easiest way for us to make cargotest use a version of procedural-masquerade that includes servo/rust-cssparser#274?

[SimonSapin]

The easiest is probably to use a more recent servo/servo commit. This is the latest:

diff --git src/tools/cargotest/main.rs src/tools/cargotest/main.rs
index 8aabe077cf1..dc09e7ffc1d 100644
--- src/tools/cargotest/main.rs
+++ src/tools/cargotest/main.rs
@@ -43,7 +43,7 @@ struct Test {
     Test {
         name: "servo",
         repo: "https://github.com/servo/servo",
-        sha: "caac107ae8145ef2fd20365e2b8fadaf09c2eb3b",
+        sha: "90e8e19f5e53fe35ab15e372c359ba681c8bc843",
         lock: None,
         // Only test Stylo a.k.a. Quantum CSS, the parts of Servo going into Firefox.
         // This takes much less time to build than all of Servo and supports stable Rust.

[Aaron1011]

@petrochenkov: I've adjusted the pretty-print hack, which makes cssparser compile.

[petrochenkov]

@bors r+

[bors]

📌 Commit baefba8 has been approved by petrochenkov

[bors]

⌛ Testing commit baefba8 with merge 192c7db...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 192c7db to master...