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

Stabilize `unrestricted_attribute_tokens` #57367

Open
wants to merge 2 commits into
base: master
from

Conversation

@petrochenkov
Copy link
Contributor

petrochenkov commented Jan 6, 2019

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

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Jan 6, 2019

@@ -689,6 +687,8 @@ declare_features! (
(accepted, repr_packed, "1.33.0", Some(33158), None),
// Allows calling `const unsafe fn` inside `unsafe` blocks in `const fn` functions.
(accepted, min_const_unsafe_fn, "1.33.0", Some(55607), None),
// support for arbitrary delimited token streams in non-macro attributes
(accepted, unrestricted_attribute_tokens, "1.33.0", Some(55208), None),

This comment has been minimized.

@Centril

Centril Jan 6, 2019

Contributor
Suggested change Beta
(accepted, unrestricted_attribute_tokens, "1.33.0", Some(55208), None),
(accepted, unrestricted_attribute_tokens, "1.34.0", Some(55208), None),

The master=>beta promotion happens on the 15th of January and FCP takes at least 10 days so this won't make it to 1.33. So this will be 1.34 at earliest unless we beta-backport (which we usually don't do for new features...? with uniform_paths being the exception...)

Show resolved Hide resolved src/test/ui/attr-eq-token-tree.rs

@Centril Centril added the relnotes label Jan 6, 2019

@CAD97

This comment has been minimized.

Copy link
Contributor

CAD97 commented Jan 7, 2019

Minor note: it might make sense to frame this not as "stabilizing unrestricted_attribute_tokens" but as stabilizing a non-problematic subset. There's still intent (as far as I've seen) to expand the ability of key-value style attributes, but that's much more complicated than the delimited style.

So my "suggestion" is to make the stabilized subset stable under unrestricted_delimited_attributes or similar, and leave the current capability of unrestricted_attribute_tokens to be discussed in the RFC for expanding the "-value" grammar of key-value attributes.

Also, cc rust-lang-nursery/wg-grammar#13, @eddyb. This grammar is the current grammar in that (permissive) grammar draft, but this probably should be linked.

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 7, 2019

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

bors added a commit that referenced this pull request Jan 16, 2019

Auto merge of #57321 - petrochenkov:atokens, r=nikomatsakis
Implement basic input validation for built-in attributes

Correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes, built-in attributes must also fit into the "meta-item" syntax (aka the "classic attribute syntax").

For some subset of attributes (found by crater run), errors are lowered to deprecation warnings.

NOTE: This PR previously included #57367 as well.
@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 27, 2019

Stabilization proposal

I propose that we stabilize #![feature(unrestricted_attribute_tokens)].

@rfcbot merge

Version target

The next version is 1.34 which goes into beta around 2019-03-01.

What is stabilized

The formal grammar (in the lyg notation) of attributes becomes:

OuterAttr = "#" attr:Attr;
InnerAttr = "#" "!" attr:Attr;
Attr = "[" path:Path input:AttrInput? "]";
AttrInput =
  | "(" TOKEN_STREAM ")"
  | "[" TOKEN_STREAM "]"
  | "{" TOKEN_STREAM "}"
  | "=" LITERAL // Unsuffixed literals only.
  ;

As a result, users may for example write #[proptest(0..1)] or #[serde(T: Display)].

Motivation

The general motivation for allowing this is to facilitate more natural and expressive EDSLs in attributes as opposed to wrapping things in strings. Moreover, this brings the grammar of attributes closer to that of regular macros.

Tests

What is not

Users are not yet permitted to write:

  • #[foo = 1 + 2] since that does not match the grammar above.
  • #[foo = 42usize] since only unsuffixed literals are permitted per grammar above.

History

  • Originally proposed: In an internals thread by @petrochenkov and @CAD97.
  • No RFC was accepted; but there is not much language design and open questions to be done here and this adds immediate value. If an RFC were to be written it would essentially elaborate on what I've written here.
  • Built-in attributes hardened and validated in #57321 which was reviewed by @Centril and @nikomatsakis.
  • Tracking issue: #55208
@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Jan 27, 2019

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Feb 11, 2019

Review pings @cramertj, @joshtriplett, @nikomatsakis, @pnkfelix, @scottmcm, and @withoutboats -- have a look? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment