Repository navigation
[1.38] Placement new syntax no longer parses #62617
Description
root: mbox 0.3.1; cc @kennytm causes:
root: rayon-hash 0.2.0 cc @cuviper
Root cause of these on our side is #60803 which removed support for parsing placement new even under #[cfg(false)] and the like. The crater run done there seems to have not found these -- not sure why. We might be testing more now than we were before.
Activity
kennytm commentedon Jul 12, 2019
The
<-support inmboxhas been removed in 0.5.0.The
mbox 0.3.1dependency was introduced bysystemd 0.1.0, but the current version issystemd 0.4.0which doesn't depend onmbox.resin-os/healthdog-rsdepends onsystemd 0.*so acargo updateis enough to remove the brokenmboxdependency.FYI @willnewton you may want to run
cargo updateto update theCargo.lock.cuviper commentedon Jul 12, 2019
rayon-hashcame up in #50832 and was fixed in 0.3.0. It's up to 0.5.0 now, and deprecated in favor ofhashbrown/rayonanyway. @coder543 should update, if thisxrayproject is at all active.coder543 commentedon Jul 12, 2019
@cuviper
xrayis unfortunately not being developed any further at this timecoder543 commentedon Jul 12, 2019
@Mark-Simulacrum those "ccs" you tried to do to tag people don't work because you put them in code blocks, just FYI...
cuviper commentedon Jul 12, 2019
@coder543 would you accept a PR bumping dependencies? Otherwise, maybe we should remove this repo from crater's list.
coder543 commentedon Jul 12, 2019
@cuviper yeah, either option would be fine!
Mark-Simulacrum commentedon Jul 12, 2019
That's intentional, I try to not ping downstream users before the root cause is assessed and/or addressed by that author.
coder543 commentedon Jul 12, 2019
Updated code has been merged
nagisa commentedon Jul 14, 2019
Since this syntax was never proposed for stablisation, I think it is fine to say it is an oversight/bug this unstable syntax was not gated.
If we decide we cannot feasibly to keep unstable syntax properly gated (because it would not work with
cfg, then<-parsing should be restored.nagisa commentedon Jul 14, 2019
We should decide how we want to deal with unstable syntax.
If unstable syntax like in this particular instance the
<-operator, was properly gated, people would have to always use nightly if any code uses features with unstable syntax, even if such uses appeared behind#[cfg]. The current situation ended up not gating the syntax properly which is now causing problems when changing/removing it. Tagging T-lang to make them aware of it.petrochenkov commentedon Jul 14, 2019
I try to ensure during reviews that new features changing the grammar are gated at parse time.
Mark-Simulacrum commentedon Jul 28, 2019
Removing T-compiler and nominating for T-lang -- I think we should close this; the ungated syntax landed a long time ago and we're pretty good these days about ensuring that we check grammar early enough that this isn't a problem (as @petrochenkov notes).
Centril commentedon Aug 1, 2019
Me, @cramertj, and @qmx agree with @Mark-Simulacrum's rationale and so we'll close this as resolved.