RFC: Overhaul the #[cfg(..)] pattern syntax

[sfackler]

No description provided.

[bharrisau]

Looks good. Did you want to treat the initial <p> as if it is wrapped in an 'any' block (the same behaviour as multiple #cfg currently, or an all block like an #cfg behaves currently. Or neither, to avoid any confusion?

[bharrisau]

Forgive the unterminated bracket. I'm on my phone and can't edit the message ;)

[sfackler]

My gut would be neither to avoid confusion, though defaulting to all might be reasonable.

[bharrisau]

And any is probably the most common in the rust tree.

[sinistersnare]

typo, link should point to rust/issues/2119 (s/issuse/issues)

[huonw]

I don't think it's entirely crazy for multiple cfgs to be an error indefinitely.

[lilyball]

👍 on the proposal, but I think we can make some tweaks to aid the transition.

First, multiple #[cfg(...)] items should continue to be accepted, with the current semantics. Second, a #[cfg(a,b,c)] pattern should be accepted (e.g. where there's multiple patterns), again with the current semantics.

However, if either of these cases are encountered in the wild, a warning will be emitted, with a note describing how to rewrite it. This warning will not be a lint, it will instead be built in to the #[cfg] parser, thus preventing anyone from disabling it.

At some point in the future, we can switch this to an error. And then at a later time, if we decide it's appropriate, we can then turn multiple #[cfg] attributes into an all match, as the RFC currently suggests.

[alexcrichton]

cc rust-lang/rust#2119, the very very old bug on this

[sfackler]

@kballard sounds reasonable to me.

[huonw]

Doesn't this give three ways to write all? #[cfg(a, b)] #[cfg(a)] #[cfg(b)] and #[cfg(all(a, b))]?

[sfackler]

Yes, but the first and second behaviors will trigger deprecation warnings.

Edit: Actually, the second case will in the short term be equivalent to #[cfg(any(a, b)], again with a warning.

[alexcrichton]

This was discussed in today's meeting and the decision was to merge it, thanks @sfackler!