Tracking issue for RFC 2539, "#[cfg_attr] expanding to multiple attributes"

[Centril]

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

Steps:

• Implement the RFC (@Havvy is doing this)
• Adjust documentation (issue filed against Document RFC 2539 (#[cfg_attr(p, attr1, attr2)]) reference#500)
• Stabilization PR (merged, stabilize cfg_attr_multi #57332)
• Fix the lint: Tracking issue for RFC 2539, "#[cfg_attr] expanding to multiple attributes" #54881 (comment)

Unresolved questions:

None

[Centril]

Implementation in #54862

[Centril]

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

[Centril]

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

• Unstable book
• Feature gate
  • /src/test/ui/feature-gates/feature-gate-cfg-attr-multi-1.{rs,stderr}
  • /src/test/ui/feature-gates/feature-gate-cfg-attr-multi-2.{rs,stderr}
  • /src/test/ui/feature-gates/feature-gate-cfg-attr-multi-bootstrap-1.rs
  • /src/test/ui/feature-gates/feature-gate-cfg-attr-multi-bootstrap-2.rs
• Tests
  • /src/test/ui/conditional-compilation/cfg-attr-parse.{rs,stderr}
  • /src/test/ui/conditional-compilation/cfg-attr-multi-true.{rs,stderr}
  • /src/test/ui/conditional-compilation/cfg-attr-multi-false.{rs,stderr}
  • /src/test/ui/conditional-compilation/cfg-attr-multi-invalid-2.{rs,stderr}
  • /src/test/ui/conditional-compilation/cfg-attr-multi-invalid-1.{rs,stderr}

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 Multiple Attributes in an Attribute Container 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]

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

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

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]

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]

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