Allow path as value in name-value attribute

[dtolnay]

This commit allows proc macros to take inert attributes that look like #[path = ident] or #[path = p::p::path]. Previously the rhs was only permitted to be an unsuffixed numeric literal or the identifier special cases true and false. However, parenthesized #[path(key = ident)] and #[path(key = p::p::path)] were already allowed; see https://docs.rs/cxx/0.4.4/cxx/attr.bridge.html for one attribute currently using that style.

My use case for this is related to C++ namespace support in https://github.com/dtolnay/cxx.

- #[cxx::bridge(namespace = co::stuff)] // previously only one namespace can be specified+ #[cxx::bridge]
mod ffi {
+ #[namespace = co::server] // now can allow different namespace for different stuff
extern "C++" {
...
+ }+ #[namespace = co::client]+ extern "C++" {
...
}
}

Chesterton's fence: why was the rhs syntax restricted originally? I believe this was to leave open the possibility of #[m1 = "...", m2 = "..."] syntax which would be equivalent to #[m1 = "..."] #[m2 = "..."] but more compact (this might still happen). Allowing an "arbitrary tokenstream" on the rhs would rule that out. In this PR I've still kept the rhs syntax quite restricted, adding only mod-style paths and remaining compatible with compact syntax being introduced later.

[rust-highfive]

r? @petrochenkov

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

[petrochenkov]

cc https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455 with which this extension overlaps.
(I was planning to support arbitrary expressions in this position, basically (and make them expandable), but didn't get to implementing #55414 (comment) myself and couldn't find other volunteers either.)

[dtolnay]

Expressions seems fine and is still compatible with potentially allowing attributes to be written combined like #[m1 = expr1, m2 = expr2].

Do you think we shouldn't take this PR without the bigger change in #55414 (comment)? I think they're largely orthogonal because values which are just mod-style paths would not participate in any kind of expansion described there.

[petrochenkov]

Do you think we shouldn't take this PR without the bigger change in #55414 (comment)?

Yes.
I'll try to prioritize #55414 (comment) and implement it myself sooner.

In the meantime #[path(key = p::p::path)] can be written through a string literal as #[path(key = "p::p::path")], so supporting paths here is not very urgent.

[petrochenkov]

I'll try to prioritize #55414 (comment) and implement it myself sooner.

I started working on this in #77271.

[dtolnay]

Reopening with rebase on #77271.

[petrochenkov]

This is superseded by #78837 now, but it would be nice to land the tests here, so marking this as blocked on #78837.

[bors]

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[petrochenkov]

#78837 has landed, unblocking.

[petrochenkov]

Closing due to inactivity.