Handle macros with multiple kinds, and improve errors

[joshtriplett]

(I recommend reviewing this commit-by-commit.)

Switch to a bitflags MacroKinds to support macros with more than one kind

Review everything that uses MacroKind, and switch anything that could refer to more than one kind to use MacroKinds.

Add a new SyntaxExtensionKind::MacroRules for macro_rules! macros, using the concrete MacroRulesMacroExpander type, and have it track which kinds it can handle. Eliminate the separate optional attr_ext, now that a SyntaxExtension can handle multiple macro kinds.

This also avoids the need to downcast when calling methods on MacroRulesMacroExpander, such as get_unused_rule.

Integrate macro kind checking into name resolution's sub_namespace_match, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes.

This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in failed_to_match_macro to check for a function-like invocation of a macro with no function-like rules.

Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in unresolved_macro_suggestions, which now carefully distinguishes between a kind mismatch and other errors.

This also handles cases of forward-referenced attributes and cyclic attributes.

---

In this PR, I've minimally fixed up rustdoc so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to MacroKinds, and it only works for macros that don't actually have multiple kinds. This will panic (with a todo!) if it encounters a macro with multiple kinds.

rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that.

---

r? @petrochenkov

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[theemathas]

The cyclic macro from #144579 (comment) still gets a weird diagnostic. The use line is necessary. (use-ing a macro_rules, for reasons I don't quite understand, allows using the macro before it's defined.)

[theemathas]

Is it intentional that I can define an attribute macro_rules and a function-like macro_rules, and use both independently?

This code compiles:

#![feature(macro_attr)]

macro_rules! foo {
    attr() { $($x:tt)* } => {};
}

macro_rules! foo {
    () => {};
}

#[foo]
struct Thing;

foo!();

I can even "overwrite" just part of the macro. This code compiles:

#![feature(macro_attr)]

macro_rules! foo {
    attr() { $($x:tt)* } => {};
    () => {
        compile_error!("This arm is not used");
    };
}

macro_rules! foo {
    () => {};
}

#[foo]
struct Thing;

foo!();

[joshtriplett]

@theemathas I believe that's expected. What's happening there is shadowing, and shadowing happens independently for each type of macro. A search for an attribute will skip over any fn-like macros, and vice versa.

[joshtriplett]

I've addressed all the feedback, and rebased to fix the conflict.

@rustbot ready

[petrochenkov]

r=me after addressing XXX and squashing some history to avoid things like moving MacroKinds.
@rustbot author

[joshtriplett]

@bors r=petrochenkov rollup

[bors]

📌 Commit e1fc89a has been approved by petrochenkov

It is now in the queue for this repository.