Tracking issue for arbitrary token streams in non-macro attributes (`unrestricted_attribute_tokens`)

[petrochenkov]

This issue tracks feature unrestricted_attribute_tokens introduced for future-compatibility during stabilization of macros 1.2.

The feature allows using the full macro attribute grammar for non-macro attributes:

PATH
PATH `(` TOKEN_STREAM `)`
PATH `[` TOKEN_STREAM `]`
PATH `{` TOKEN_STREAM `}`

Additionally, the feature extends the grammar of value in key-value attributes (#[key = "value"]) to arbitrary token trees:

PATH = TOKEN_TREE

More information and proposed path to stabilization can be found in https://internals.rust-lang.org/t/unrestricted-attribute-tokens-feature-status/8561.

[Centril]

cc @rust-lang/lang

I'm in favor of doing this change; all of it. But do we need this to go through an RFC first?

[flying-sheep]

I’m a bit confused: I want to use a macro invocation in the attribute value position, but apparently it doesn’t get expanded: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=14757b61cc384f085a63efea3002b96d

The code compiles, but I have no idea what actually ends up in the attribute.

[eddyb]

@flying-sheep That's not supported - serde sees what you gave it, without any expansion, e.g. #[serde(skip_serializing_if = type_is_empty!(bool))].
"Early expansion" has been discussed elsewhere, and for backwards-compatibility reasons it would have to be opt-in anyway (i.e. we can't change what the code you wrote does).

[flying-sheep]

Do you know where early expansion is discussed? I’m also be happy with #[my_macro!(...)] being possible; is that in the pipes?

[Centril]

@flying-sheep That's not supported - serde sees what you gave it, without any expansion, e.g. #[serde(skip_serializing_if = type_is_empty!(bool))].
"Early expansion" has been discussed elsewhere, and for backwards-compatibility reasons it would have to be opt-in anyway (i.e. we can't change what the code you wrote does).

@eddyb But in this case you can only pass this to serde because an opt-in feature gate has been enabled; can you elaborate on the backwards compat concern?

[eddyb]

@Centril I was talking about (early) macro expansion in general, not this specific instance.

But also, I'm pretty sure the intention is to allow free-form attribute input, which would make type_is_empty!($typ) not a macro invocation, unless serde_derive specifically treats it as such.

Meanwhile, opt-in early expansion proposals would work in this case, without attribute parsing or serde_derive knowing anything about a macro even being around.