You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)]implUnstableSyntaxfor .. {}
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:
The text was updated successfully, but these errors were encountered:
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
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?
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:
Because we only process
cfg
s after parsing, thecfg
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 iscfg
ed at it's declaration, such as:or behind a macro:
cc @petrochenkov
The text was updated successfully, but these errors were encountered: