Change:
#![feature(partition_point)] #![feature(once_cell)] #![feature(unsafe_block_in_unsafe_fn)] <ins> #![feature(int_bits_const)] </ins> #![feature(nonzero_leading_trailing_zeros)] #![feature(const_option)] #![feature(integer_atomics)]

Discussion:
I am using the latest nightly compiler build. When it got to compiling the crate: I expected to see this happen: the compilation should be completed with no errors, as with the previous nightly builds Instead, this happened: 27 errors from the crate spat on the screen. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I am not sure if it had been a bug in the type-checker, as the compilation doesn't fail on previous nightly compilers , only ocurred in the newest nightly. The related issue on lexical-core:
Some errors:
I have the exactly same issue.
Same issue. rustc --version; cargo --version; rustup --version rustc 1.51.0-nightly ( 2021-02-01) cargo 1.51.0-nightly ( 2021-01-25) rustup 1.23.1 ( 2020-11-30)
This is failing because was to the standard library and stabilized yesterday: This constant is a in the standard library, but used to resolve to a constant associated to a trait. The code now fails because it gets an where it expects a . Unfortunately, breaking things like this is always a risk when stabilizing new methods or constants.
So would it be more of an issue on side?
It wasn't really a bug in or any other crate. This is just what can happen when adding new names to the standard library. There is never a guarantee that will always resolve to the same trait, since types can always add their own associated constants and methods. could fix this issue by explicitly using instead. Depending on how big the fallout is, we might want to (temporarily) roll the stabilization of back.
Makes sense.
does warn for potential breakage before things are stabilized: However, those warnings are only visible when comping the crate directly (or as a local dependency), not when compiling it as an remote dependency, to avoid flooding people with warnings for crates they are not working on.
I wished I could just clone the crate and make the changes myself, but the only issue is it is a dependency used by sqlformat which is a dependency used by sqlx.

Is there some way to force sqlformat to use my local version instead of the remote version on
Yes, that should be possible with a section in your :
Thanks
I have the same problem. Did you do a in your ?
Yes, I cloned the repository of lexical-core and made the fixes myself.
Do you have a pointer to this fix ?
See Looks like the maintainer of hasn't been active on GitHub since March, this is going to be fun.
In the meantime, you can pop this in your root :
We are reverting stabilization of for now, until this is solved upstream.
I've submitted , and am also personal friends with the maintainer. I will take ownership of getting the crate updated.
I am now a maintainer of the family of crates. is published utilizing Gelbpunkt's fix in Alexhuszagh/rust-lexical, and is published depending on it. This should unblock this issue and resume stabilization, assuming all of 's dependents are able to receive patch updates automatically.
Thank you,
In combination with 's patch solution I guess the best fix for now is to use? (I am using some dependencies that use old versions of nom (5.*) and this is why I needed it)
has this in its , which has the fixed version in its range. Trying myself with the following , cargo brings in . It's possible that is all that is needed, without the patch, so that your is updated.
Thanks, that was indeed the case. I had tried but had forgotten about to lock-file.