Change:
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 . There was no discussion on the re-stabilization PR 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.
cc 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.
There’s no way around the symbol collision. I think it’s important that 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 ’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 for stabilization? Should I yank the conflicting versions in each minor series? Alternatively, would it make sense, and is it even possible, to stabilize only in ?
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 - 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...
The constant would have to be available everywhere, and stable everywhere, but one could think about adding a syntactic hack to interpret the syntax differently depending on the edition, similarly to how it was done for . 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.
Attaching it to an edition would not only require compiler changes, but also a lint, a suggestion for rustfix, documentation, etc.
Indeed. 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: also ignores the lock files and picks the latest matching version of everything.
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.
Thank you! Let me know if I can help.
I'm wondering if we should have a in (just like ) that will make Rustc consider everything that was stabilized in a later version as still unstable. 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.
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 :)
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. versions , , , and 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 on each of these releases with 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 to un-break your project", then is ready.
No worries. We are planning to move ahead with a compat note indicating cargo update.
Just an FYI: this was fixed ~2 months ago, with , , and . It means that any branch used in the wild should be able to be updated to a compatible version now.

Discussion:
to rejecting hexadecimal IP addresses.][83652] The octal format can lead to confusion and potential security vulnerabilities and [is no longer recommended][ietf6943]. <ins> - [The added `BITS` constant may conflict with external definitions.][85667] In particular, this was known to be a problem in the `lexical-core` crate, but they have published fixes for semantic versions 0.4 through 0.7. To update this dependency alone, use `cargo update -p lexical-core`. </ins> Internal Only -------------

- [rustdoc: Only look at blanket impls in `get_blanket_impls`][83681] - [Rework rustdoc const type][82873] <ins> [85667]: https://github.com/rust-lang/rust/pull/85667 </ins> [83386]: https://github.com/rust-lang/rust/pull/83386 [82771]: https://github.com/rust-lang/rust/pull/82771 [84147]: https://github.com/rust-lang/rust/pull/84147