Implement declarative (macro_rules!) attribute macros (RFC 3697)

[joshtriplett]

This implements RFC 3697, "Declarative (macro_rules!) attribute macros".

I would suggest reading this commit-by-commit. This first introduces the
feature gate, then adds parsing for attribute rules (doing nothing with them),
then adds the ability to look up and apply macro_rules! attributes by path,
then adds support for local attributes, then adds a test, and finally makes
various improvements to errors.

[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

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[theemathas]

Here's an edge case that probably needs a test.

Code and error

#![feature(macro_attr)]

#[foo]
macro_rules! foo {
    attr() { $($body:tt)* } => {
        $($body)*
    }
}
use foo;

warning: unused macro definition: `foo`
 --> src/lib.rs:4:14
  |
4 | macro_rules! foo {
  |              ^^^
  |
  = note: `#[warn(unused_macros)]` on by default

error: cannot determine resolution for the attribute macro `foo`
 --> src/lib.rs:3:3
  |
3 | #[foo]
  |   ^^^
  |
  = note: import resolution is stuck, try simplifying macro imports

warning: `foo` (lib) generated 1 warning
error: could not compile `foo` (lib) due to 1 previous error; 1 warning emitted

[joshtriplett]

@theemathas I can't reproduce that here. I get a different error instead:

error: cannot find attribute `foo` in this scope
  --> $DIR/macro-rules-attr-cycle.rs:4:3
   |
LL | #[foo]
   |   ^^^
LL | macro_rules! foo {
   |              --- `foo` exists, but has no `attr` rules

This isn't the right error message, but the error is getting caught.

(Suggestions welcome for how to catch and handle this case better.)

[joshtriplett]

@theemathas I looked into your test case more. I managed to find a way to reproduce the error you got; it only reproduces if there aren't other errors. So, I can reproduce it with the following test:

#![crate_type = "lib"]
#![feature(macro_attr)]

#[attr]
macro_rules! attr {
    attr() {} => {}
}

#[attr]
struct S;

This gives:

error: cannot find attribute `attr` in this scope
  --> /home/josh/src/rust/tests/ui/macros/macro-rules-attr-apply-to-self.rs:4:3
   |
LL | #[attr]
   |   ^^^^
LL | macro_rules! attr {
   |              ---- `attr` exists, but has no `attr` rules

error: cannot determine resolution for the attribute macro `attr`
  --> /home/josh/src/rust/tests/ui/macros/macro-rules-attr-apply-to-self.rs:9:3
   |
LL | #[attr]
   |   ^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

The second error seems reasonable for attempting to invoke an attribute on itself.

The first error also largely seems fine, except that it shouldn't say has no `attr` rules when the real problem is a cycle.

Note that "cannot find" is the same error that you get if you try this:

mac! {
    macro_rules! mac {
        {} => {}
    }
}

mac! {
    struct S;
}

This gives:

error: cannot find macro `mac` in this scope
 --> src/main.rs:1:1
  |
1 | mac! {
  | ^^^

error: cannot find macro `mac` in this scope
 --> src/main.rs:7:1
  |
7 | mac! {
  | ^^^

So, I think "cannot find ... in this scope" is an acceptable error, albeit one we might be able to improve. I think the main problem here is the spurious `attr` exists, but has no `attr` rules.

[joshtriplett]

I think this is ready for review. The error messages could always be better, and there are additional cases that need handling (notably glob imports), but I think it would help to have some review before tackling those.

[petrochenkov]

(I started looking today, but will continue only on ~Monday.)

[rustbot]

rustc_errors::emitter was changed

cc @Muscraft

[joshtriplett]

I've rebased the series to eliminate all cases of a commit later in the series fixing code introduced earlier in the series. I've confirmed that the result is identical to the final result after the previous series, and that ./x test ui --test-args macro compiles and passes tests after every commit.

The commits now follow a logical progression:

• Fix an error message (from outside this series) that assumed all attributes were proc macros.
• Parse attr rules, including tests for the parser and its error messages. This makes MacroRule an enum, and updates every user of it to check for the Func variant, but leaves the Attr variant marked as unused since nothing ever looks for it.
• Introduce some new error messages that make sense now that attr rules exist.
• Handle non-local macro attributes.
• Handle local macro attributes.
• Add a pile of tests.

@bors r=petrochenkov rollup

[bors]

📌 Commit f88839d has been approved by petrochenkov

It is now in the queue for this repository.

[bors]

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

[tgross35]

Somehow this seems to have slightly improved tokentree muching performance :) #145126 (comment)

[joshtriplett]

Somehow this seems to have slightly improved tokentree muching performance :) #145126 (comment)

Fun! That's comforting to hear, I had worried it might have a performance impact.

[joshtriplett]

@theemathas Turns out your cyclic attr test case is also getting fixed by @petrochenkov's suggestion to handle multiple macro kinds up front. That led to fixing the diagnostics to better distinguish between various error cases.

[joshtriplett]

@petrochenkov #145153 implements the change to support a macro with multiple kinds. Turned out very nicely, and led naturally to fixing and cleaning up various things. Thanks!