Could not compile lexical-core on latest nightly, possibly a type checker issue?

[HTGAzureX1212]

I am using the latest nightly compiler build. When it got to compiling the lexical-core 0.7.4 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.

Meta

rustc --version --verbose:

rustc 1.51.0-nightly (d4e3570db 2021-02-01)
binary: rustc
commit-hash: d4e3570db4c007089035b833cc20c7fc2f8cb32f
commit-date: 2021-02-01
host: x86_64-pc-windows-msvc
release: 1.51.0-nightly
LLVM version: 11.0.1

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: Alexhuszagh/rust-lexical#55

[HTGAzureX1212]

Some errors:

error[E0308]: mismatched types
  --> C:\Users\<user>\.cargo\registry\src\git.colasdn.top-1ecc6299db9ec823\lexical-core-0.7.4\src\atof\algorithm\bhcomp.rs:62:24
   |
62 |     let bytes = bits / Limb::BITS;
   |                        ^^^^^^^^^^ expected `usize`, found `u32`

error[E0277]: cannot divide `usize` by `u32`
  --> C:\Users\<user>\.cargo\registry\src\git.colasdn.top-1ecc6299db9ec823\lexical-core-0.7.4\src\atof\algorithm\bhcomp.rs:62:22
   |
62 |     let bytes = bits / Limb::BITS;
   |                      ^ no implementation for `usize / u32`
   |
   = help: the trait `Div<u32>` is not implemented for `usize`

[maekawatoshiki]

I have the exactly same issue.

[sbnl]

Same issue.
rustc --version; cargo --version; rustup --version

rustc 1.51.0-nightly (d4e3570 2021-02-01)
cargo 1.51.0-nightly (c3abcfe8a 2021-01-25)
rustup 1.23.1 (3df2264a9 2020-11-30)

[m-ou-se]

This is failing because <integer>::BITS was added to the standard library and stabilized yesterday: #76904

This constant is a u32 in the standard library, but Limb::BITS used to resolve to a usize constant associated to a trait. The code now fails because it gets an u32 where it expects a usize.

Unfortunately, breaking things like this is always a risk when stabilizing new methods or constants.

[HTGAzureX1212]

So would it be more of an issue on lexical-core side?

[m-ou-se]

It wasn't really a bug in lexical-core or any other crate. This is just what can happen when adding new names to the standard library. There is never a guarantee that Type::something will always resolve to the same trait, since types can always add their own associated constants and methods.

lexical-core could fix this issue by explicitly using <Limb as SomeTrait>::BITS instead.

Depending on how big the fallout is, we might want to (temporarily) roll the stabilization of <integer>::BITS back.

[HTGAzureX1212]

Makes sense.

[m-ou-se]

rustc does warn for potential breakage before things are stabilized:

warning: a method with this name may be added to the standard library in the future
    --> src/atof/algorithm/math.rs:1909:34
     |
1909 | const ALGORITHM_D_B: Wide = 1 << Limb::BITS;
     |                                  ^^^^^^^^^^
     |
     = note: `#[warn(unstable_name_collisions)]` on by default
     = warning: once this method is added to the standard library, the ambiguity may cause an error or change in behavior!
     = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
     = help: call with fully qualified syntax `util::num::Integer::BITS(...)` to keep using the current method

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.

[HTGAzureX1212]

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 crates.io?

[m-ou-se]

@HTG-YT Yes, that should be possible with a [patch] section in your Cargo.toml: https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section

[HTGAzureX1212]

Thanks