Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
petrochenkov opened this Issue Oct 19, 2018 · 8 comments

Comments

Projects
None yet
5 participants
@petrochenkov
Copy link
Contributor

petrochenkov commented Oct 19, 2018

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

This comment has been minimized.

Copy link
Contributor

Centril commented Nov 10, 2018

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

This comment has been minimized.

Copy link

flying-sheep commented Dec 3, 2018

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

This comment has been minimized.

Copy link
Member

eddyb commented Dec 3, 2018

@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

This comment has been minimized.

Copy link

flying-sheep commented Dec 3, 2018

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

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Dec 3, 2018

@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

This comment has been minimized.

Copy link
Member

eddyb commented Dec 3, 2018

@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.

bors added a commit that referenced this issue Jan 4, 2019

Auto merge of #57321 - petrochenkov:atokens, r=<try>
Implement basic input validation for built-in attributes + Stabilize `unrestricted_attribute_tokens`

Based on #57272

---

In accordance with the plan in https://internals.rust-lang.org/t/unrestricted-attribute-tokens-feature-status/8561:
- The correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes.
- For non-built-in non-macro attributes:
    - The key-value form is restricted to bare minimum required to support what we support on stable - unsuffixed literals (#34981).
    - Arbitrary token streams in remaining forms (`#[attr(token_stream)]`, `#[attr{token_stream}]`, `#[attr[token_stream]]` ) are now allowed without a feature gate, like in macro attributes.

This will close #55208 once completed.
Need to go through crater first.
@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Jan 4, 2019

PR implementing the stabilization plan - #57321.

@shepmaster

This comment has been minimized.

Copy link
Member

shepmaster commented Jan 27, 2019

Followup PR implementing the stabilization plan - #57367

bors added a commit that referenced this issue Feb 25, 2019

Auto merge of #57367 - petrochenkov:unrestab, r=Centril
Stabilize `unrestricted_attribute_tokens`

In accordance with a plan described in https://internals.rust-lang.org/t/unrestricted-attribute-tokens-feature-status/8561/3.

Delimited non-macro non-builtin attributes now support the same syntax as macro attributes:
```
PATH
PATH `(` TOKEN_STREAM `)`
PATH `[` TOKEN_STREAM `]`
PATH `{` TOKEN_STREAM `}`
```
Such attributes mostly serve as inert proc macro helpers or tool attributes.
To some extent these attributes are de-facto stable due to a hole in feature gate checking (feature gating is done too late - after macro expansion.)
So if macro *removes* such helper attributes during expansion (and it must remove them, unless it's a derive macro), then the code will work on stable.

Key-value non-macro non-builtin attributes are now restricted to bare minimum required to support what we support on stable - unsuffixed literals (#34981).
```
PATH `=` LITERAL
```
(Key-value macro attributes are not supported at all right now.)
Crater run in #57321 found no regressions for this change.
There are multiple possible ways to extend key-value attributes (#57321 (comment)), but I'd expect an RFC for that and it's not a pressing enough issue to block stabilization of delimited attributes.

Built-in attributes are still restricted to the "classic" meta-item syntax, nothing changes here.
#57321 goes further and adds some additional restrictions (more consistent input checking) to built-in attributes.

Closes #55208

@bors bors closed this in #57367 Feb 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.