regression: BITS constant conflicts in lexical crates

[Mark-Simulacrum]

u/iN::BITS was re-stabilized in 1.53 after being backed out of 1.51 due to breakage, primarily in the lexical-core crate. This breakage has not been fixed, as far as I can tell, in a vast majority of crates: we're still seeing ~1300 regressions, majority of which are lexical-core in the beta crater run.

There was no discussion on the re-stabilization PR #82565 (comment) as to whether this level of breakage is acceptable. Comments on the original breakage issue suggest that 0.7.5 was published with a fix, but older versions (0.4, 0.5, 0.6) did not receive similar treatment.

The majority of the breakage is in crates locked at 0.7.4; the other versions do share ~400 different crates amongst them, so I think it'd be good to try and help get those series patches as well.

[Mark-Simulacrum]

cc @m-ou-se @myrrlyn

Even with 0.7.5 out, it does look like it'll be some time before crates actually update lockfiles (if ever). We don't have a firm policy on whether cargo update being sufficient is "enough" that breakage is OK -- it's a new decision each time pretty much -- but this level of breakage is pretty bad. I guess there may not be much we can do -- IIRC a prelude trait for example adding BITS wouldn't help here, right? Those still introduce conflicts IIRC.

[myrrlyn]

There’s no way around the symbol collision. I think it’s important that ::BITS stabilize and I’d like us to get out of the way on that.

I can take the list of broken crates and start walking it. I can also work on a backport on the older minor series; the reason I did not do so last time is that I was unfamiliar with lexical-core’s dependents and didn’t know whether the older series were still in use.

What is the most complete course of action we can take to clear ::BITS for stabilization? Should I yank the conflicting versions in each minor series?
Alternatively, would it make sense, and is it even possible, to stabilize ::BITS only in e2021?

[Mark-Simulacrum]

I wouldn't worry about filing pull requests with 1300+ crates bumping lock files (in part because those are unlikely to get merged quickly).

I do think getting patch releases out for each series would already be a significant step forward. I think yanking is likely not the right step to take at this time.

In terms of stabilizing only with e2021- no, that's not really possible. In theory we could stabilize with a different name to avoid all the breakage, but I doubt there's a great name...

[est31]

is it even possible, to stabilize ::BITS only in e2021?

The constant would have to be available everywhere, and stable everywhere, but one could think about adding a syntactic hack to interpret the ::BITS syntax differently depending on the edition, similarly to how it was done for into_iter. That would have the desired effect of avoiding breakage on editions 2018 and before, but I'm not sure it's a good idea to double down on adding such hacks.

[m-ou-se]

Attaching it to an edition would not only require compiler changes, but also a lint, a suggestion for rustfix, documentation, etc.

[m-ou-se]

IIRC a prelude trait for example adding BITS wouldn't help here, right?

Indeed.

We don't have a firm policy on whether cargo update being sufficient is "enough" that breakage is OK

Such a policy would be useful. If the decision is that that's fine, we might want to make crater update the lock files when something fails before it considers a crate broken.

As another data point: cargo install also ignores the lock files and picks the latest matching version of everything.

[myrrlyn]

I assumed the edition route was an infeasible idea but hey might as well get a “no” in writing.

I’ll start cutting fixes for the minor series listed in the regression report this weekend.

[m-ou-se]

I’ll start cutting fixes for the minor series listed in the regression report this weekend.

@myrrlyn Thank you! Let me know if I can help.

[m-ou-se]

I'm wondering if we should have a std_version = "1.52.0" in Cargo.toml (just like edition = ..) that will make Rustc consider everything that was stabilized in a later version as still unstable. cargo publish could add it to the uploaded crate if it's not explicitly set, and it makes it easier for crates to track an explicit MSRV.

[Mark-Simulacrum]

@myrrlyn did you get a chance to release new patch releases on each of the channels to avoid this breakage for the lexical crates, at least? I believe that was the plan but I haven't seen updates on this issue at least :)

[myrrlyn]

Hi; I am so sorry for the radio silence; I have had quite the month since then. Fortunately, Alex Huszagh already did the patch-release issuance back in April.

lexical-core versions 0.4.8, 0.5.1, 0.6.8, and 0.7.6 all appear to have the necessary disambiguation in place. These versions also do not appear in the regression report from Bors. I've also run cargo check on each of these releases with #![feature(int_bits_const)] and passed, so these tips ought to be correct when the constants stabilize.

I hope day-before isn't too late and I apologize again for the delay. If you're comfortable with a "run cargo update to un-break your project", then lexical-core is ready.

[Mark-Simulacrum]

No worries. We are planning to move ahead with a compat note indicating cargo update.

[Alexhuszagh]

There was no discussion on the re-stabilization PR #82565 (comment) as to whether this level of breakage is acceptable. Comments on the original breakage issue suggest that 0.7.5 was published with a fix, but older versions (0.4, 0.5, 0.6) did not receive similar treatment.

Just an FYI: this was fixed ~2 months ago, with v0.4.8, v0.5.1, and v0.6.8. It means that any branch used in the wild should be able to be updated to a compatible version now.