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 RFC 2539, "#[cfg_attr] expanding to multiple attributes" #54881

Open
Centril opened this Issue Oct 7, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@Centril
Contributor

Centril commented Oct 7, 2018

This is a tracking issue for the RFC "#[cfg_attr] expanding to multiple attributes" (rust-lang/rfcs#2539).

Steps:

Unresolved questions:

None

@Centril

This comment has been minimized.

Contributor

Centril commented Oct 7, 2018

Implementation in #54862

@Centril

This comment has been minimized.

Contributor

Centril commented Nov 11, 2018

Setting earliest date for stabilization proposal: 2018-11-22 (11 days from now).

@Centril

This comment has been minimized.

Contributor

Centril commented Nov 25, 2018

Stabilization proposal

@rfcbot merge

Originally proposed in RFC rust-lang/rfcs#2539, implemented in #54862, and in nightly since ~ the 12th October, cfg_attr_multi allows users to specify multiple attributes in cfg_attr(condition, foo, bar) where foo and bar are the attributes to expand should condition hold. The benefit of cfg_attr_multi is ergonomics but also readability and maintainability; you avoid having to specify condition several times. This can be particularly beneficial if condition is long and non-trivial.

Version target

The next version is 1.32 which goes into beta the 7th of December; It is quite possible that this will slip into 1.33 however depending on how long the review process takes.

What is stabilized

Users are now permitted to write for example:

#[cfg_attr(all(),)] struct A; // trailing comma permitted as well as zero items.
#[cfg_attr(all(), must_use)] struct A;
#[cfg_attr(all(), must_use,)] struct A; // trailing permitted.
#[cfg_attr(foo, must_use, deprecated)] struct A;
#[cfg_attr(all(), must_use, deprecated,)] struct A; // trailing permitted.

The semantics of these are to expand to for example #[must_use] #[deprecated] on struct A if foo should hold (4th example).

If zero attributes are given, e.g. #[cfg_attr(all(),)] then unused_attributes the lint will be emitted. This behaviour is not witnessed in the current nightly compiler; that is OK since it's a minor issue but it will need to be fixed in the stabilization PR. See https://github.com/rust-lang/rust/blob/master/src/libsyntax/config.rs#L145.

What is not

Users are not permitted to write:

  • More than one trailing comma, e.g. #[cfg_attr(all(), must_use, deprecated,,)]
  • Zero attributes and no comma, e.g. #[cfg_attr(all())]
  • An empty cfg_attr, e.g. #[cfg_attr()]
  • #[foo, bar]; this is proposed in rust-lang/rfcs#2600.
    This stabilization is forward compatible with that RFC.

Divergences from RFC

None


cc @Havvy can you make the stabilization PR + resolve the minor FIXME in it?
Also cc @petrochenkov who reviewed the implementation.

@rfcbot

This comment has been minimized.

rfcbot commented Nov 25, 2018

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

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.

@Havvy

This comment has been minimized.

Contributor

Havvy commented Nov 25, 2018

I wouldn't call the implementation of the lint a minor fix. The first time I tried, I bailed when I hit a set of cases I couldn't get something the lint infrastructure wanted.

The lint is also the least value add of the RFC and I propose stabilizing it separately if doing so doesn't break backwards compatibility.

@Centril

This comment has been minimized.

Contributor

Centril commented Nov 25, 2018

@Havvy Warn by default lints can always be added later so if you think it is non-trivial to implement in the stabilization PR, I wouldn't mind deferring that to the future; as you say, it is indeed the least value-add. However, if you do manage to fix it in the stabilization PR, that would be nice (but not required, imo).

@rfcbot

This comment has been minimized.

rfcbot commented Dec 10, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

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