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\github.aaakk.us.kg-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\github.aaakk.us.kg-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

[catenacyber]

@HTG-YT I have the same problem. Did you do a patch in your Cargo.toml ?

[HTGAzureX1212]

Yes, I cloned the repository of lexical-core and made the fixes myself.

[catenacyber]

Do you have a pointer to this fix ?

[trevyn]

@catenacyber See Alexhuszagh/rust-lexical#56

Looks like the maintainer of lexical-core hasn't been active on GitHub since March, this is going to be fun.

[trevyn]

In the meantime, you can pop this in your root Cargo.toml:

[patch.crates-io]
lexical-core = {git = 'https://github.com/Gelbpunkt/rust-lexical', branch = 'fix-warnings-and-update-deps'}

[m-ou-se]

We are reverting stabilization of ::BITS for now, until this is solved upstream.

[jhoobergs]

I am now a maintainer of the lexical family of crates. lexical-core 0.7.5 is published utilizing Gelbpunkt's fix in Alexhuszagh/rust-lexical#56, and lexical 5.2.1 is published depending on it. This should unblock this issue and resume stabilization, assuming all of lexical's dependents are able to receive patch updates automatically.

In combination with @trevyn 's patch solution I guess the best fix for now is to use?

[patch.crates-io]
lexical-core = {git = 'https://github.com/Alexhuszagh/rust-lexical' }

(I am using some dependencies that use old versions of nom (5.*) and this is why I needed it)

[memoryruins]

@jhoobergs nom 5.1.2 has this in its Cargo.toml, which has the fixed version in its range.

[dependencies.lexical-core]
optional = true
version = ">= 0.6, < 0.8"

Trying myself with the following Cargo.toml, cargo brings in lexical-core 0.7.6.

[dependencies]
nom = "5"

It's possible that cargo update -p lexical-core is all that is needed, without the patch, so that your Cargo.lock is updated.
https://doc.rust-lang.org/cargo/commands/cargo-update.html

[jhoobergs]

Thanks, that was indeed the case. I had tried cargo clean but had forgotten about to lock-file.