Split AttrArgs from MacArgs.

[nnethercote]

MacArgs is confusing. It has three variants. It's used in two
different cases.

• Attributes, where all three variants are used.
• Function-like macro calls, where only one variant is used.

This commit separates these two cases. AttrArgs keeps much of the
functionality of the old MacArgs. The new MacArgs is a greatly
streamlined version of the old MacArgs. There is a small amount of
code duplication, but I think this change improves readability. It also
lets a few unreachable code paths (e.g. unwrap/expect calls) be
removed.

The commit also renames MacDelimeter as AttrMacDelimeter, because
it's used for both AttrArgs and MacArgs. For this type, it makes
more sense to share a single type between the two cases because all
variants and methods are used in both cases.

r? @matthiaskrgr

[rust-highfive]

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

Some changes occurred in src/tools/rustfmt.

cc @rust-lang/rustfmt

[petrochenkov]

It's used in two different cases

Those two are the same case, that's why I introduced MacArgs in #66935.
I'll look what this PR does, but I'm generally against the idea.

[nnethercote]

In what way are they the same case?

I found this naming confusing. I also don't like it when types allow invalid values, e.g. if a macro call involves a MacArgs::Eq or MacArgs::Empty value.

[petrochenkov]

I reviewed the changes, and I'm still against doing this.

First about the terminology - Mac here means any macro, including attributes and potentially derives when the #[derive(DeriveMacro(args...))] syntax is supported.
That's why fn-like macro calls are specifically called MacCall in AST.
So MacArgs are arguments to any kinds of macros, and they turn into the same thing when reaching proc macro interface in particular.

Second, I'd like to keep MacArgs::Empty for fn-like macro calls at least for recovery, because macro "constants" let foo = FOO!; (#66935 (comment)) are a quite reasonable thing with an obvious meaning since "word" attributes #[foo] are already long supported, there was just not enough push to adopt them officially.

This only leaves MacArgs::Eq as an impossible case, but I think it's more important to keep all the arguments unified than to eliminate it.

[bors]

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