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

Don't use unstable syntax without some sort of parsing guard #156

Closed
leoyvens opened this issue Feb 8, 2018 · 1 comment
Closed

Don't use unstable syntax without some sort of parsing guard #156

leoyvens opened this issue Feb 8, 2018 · 1 comment

Comments

@leoyvens
Copy link

leoyvens commented Feb 8, 2018

We had a situation in rust-lang/rust#46480 where we had trouble removing support for an unstable syntax in the parser because a popular crate (crossbeam) used the syntax behind a simple feature gate:

#[cfg(nightly)]
impl UnstableSyntax for .. {}

Because we only process cfgs after parsing, the cfg doesn't help at all in this case, causing de facto stability of the parser's support for unstable syntax. This situation is likely to repeat itself, we must teach lib authors to only use unstable syntax inside a mod that is cfged at it's declaration, such as:

#[cfg(nightly)]
mod contains_unstable_syntax;

or behind a macro:

#[cfg(nightly)]
macro_rules unstable_syntax! { /* expand to unstable syntax */ }

#[cfg(not(nightly))]
macro_rules unstable_syntax! { /* expand to nothing */ }

cc @petrochenkov

@leoyvens leoyvens changed the title Don't use unstable syntax without some sort of future proofing Don't use unstable syntax without some sort of parsing guard Feb 8, 2018
@KodrAus
Copy link
Contributor

KodrAus commented Feb 9, 2018

Hmm, this is a tricky and subtle situation. Is there any solution to this on the compiler side rather than in libraries? If not, maybe we can frame this as a more general guideline for structuring your library that supports both stable and optional nightly features?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants