Repository navigation
Crates using placement syntax behind a cfg broken #50832
Description
Activity
- addedT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.C-bugCategory: This is a bug.Category: This is a bug.
on May 17, 2018 It is already fixed in
mbox 0.5.0and0.4.4.Oh, that's annoying. We should patch rayon-hash.
This is not the first time this is happening, removal of
impl Trait for .. {}caused same consequences (see #46480).
We should probably continue parsing<-and report the error later in AST validation.Reacted by Esteban KuberDiscussed in the @rust-lang/compiler meeting. I think we reached this consensus:
- in this case, yes, we should do as @petrochenkov suggests: keep parsing, error in AST validation
- if in the future, if it happens that we want to repurpose the syntax, we deal with it then: best of course is to use an edition for it, but maybe by then there no longer exist crates using it
- going forward, it would be ideal if we could do some kind of "pre-cfg / expansion" feature check to try and avoid this in the future; that may or may not be feasible though, and we couldn't do it retroactively for all existing things anyway
Some discussion of the final at or around here in the IRC logs
https://botbot.me/mozilla/rustc/2018-05-17/?msg=100165163&page=3
triage: P-high
Would anyone have time to whip up a change to the parser?
cc @rust-lang/compiler @aidanhs
For reference, the PR that reverted the syntax was #48333
I am working on rayon-hash. The quick hack would be to just nuke the placement stuff, but I'm trying to do a proper update to catch up to
std's code -- fun withgit subtree.But frankly, I don't know of anyone really using rayon-hash anyway.
Fixed in rayon-hash 0.3.0.
I'll handle this.
Restored in #51052
We could try calling more attention to lib authors about this through the API guidelines.
- added a commit that references this issue
on May 26, 2018 The two regressions where about
<-, but we also reverted theinsyntax as well, which has degraded back a couple of errors, like the following:fn main() { let i = (); for x in in 0..1 {} i; }Would it be ok to create a PR removing the
inparsing while keeping the current<-handling for a while longer?
Some crates were using
<-behind a feature flag, so they worked on stable even if the placement syntax was nightly-only. After removing it though they fail to compile even on stable with a syntax error, because<-is not recognized anymore.