Find last compiling version if Cargo.lock is gone

help
1

Hello,

my Cargo.toml included

rayon = "1.5.1"

and everything compiled fine with the newest nightly version. Then I deleted my Cargo.lock file and it does no longer compile (on nightly), because rayon indirectly depends on crossbeam-epoch=0.9.8 which does not compile on nightly. crossbeam-epoch=0.8.2 compiles on nightly. I ended up removing rayon as a dependency because it is not that important in my project, but I am still asking:

  • Is this a bug on rayon's behalf?
  • How am I supposed to find the last compiling version of crossbeam-epoch force rayon to use it?
  • How should something like this work in the rust ecosystem.
2

I cannot reproduce the issue; crossbeam-epoch 0.9.8 compiles with no errors on the latest nightly version. What output do you get when you run rustc +nightly -V -v?

Regarding forcing specific versions of a dependency, this can be done with cargo update -p my-crate --precise 1.2.3. You can adjust the version number and recompile as necessary to find the latest working version.

3

I thought that pacman -Syu would update rustc if the rustup package is installed... Nope, it does not. With the newest nightly (a.k.a. rustup update) it compiles.

Is there a script to automate this? Since dependencies are a tree, not a list this can be quite tedious.

4

The first step is to determine which dependency is causing the error. For instance, if I compile a crate with dependency rayon = "1.5.1" with rustc version nightly-2022-03-07, I get this error:

error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable
   --> /home/lm978/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-epoch-0.9.8/src/atomic.rs:314:6
    |
314 | impl<T: ?Sized + Pointable> Atomic<T> {
    |      ^
...
346 |     pub const fn null() -> Atomic<T> {
    |     -------------------------------- function declared as const here
    |
    = note: see issue #93706 <https://github.com/rust-lang/rust/issues/93706> for more information
    = help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable

For more information about this error, try `rustc --explain E0658`.
error: could not compile `crossbeam-epoch` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

Here, the 3rd-to-last line tells us that the dependency crossbeam-epoch failed to compile. So now we can start working backward until it compiles, using the crates.io page as a source of version numbers:

$ cargo update
    Updating crates.io index
$ cargo +nightly-2022-03-07 build
[...]
error: could not compile `crossbeam-epoch` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed
$ cargo update -p crossbeam-epoch --precise 0.9.8
    Updating crates.io index
$ cargo update -p crossbeam-epoch --precise 0.9.7
    Updating crates.io index
    Updating crossbeam-epoch v0.9.8 -> v0.9.7
$ cargo +nightly-2022-03-07 build
[...]
    Finished dev [unoptimized + debuginfo] target(s) in 2.35s

In this case, the process is pretty short, since crossbeam-epoch v0.9.7 supports nightly-2022-03-07. But if it still fails, then we'd keep going through the version numbers until we find a version that does compile. If there's no version that is compatible and also compiles, then we're out of luck.

In this case, you only had an issue due to using a too-old rustc version: the latest version of crossbeam-epoch expects a version no older than nightly-2022-03-08. It's very rare in general for a crate that works on older compilers to stop working on newer compilers, due to Rust's stability guarantees. The only exception to this is crates that use unstable features: since nightly Rust has no guarantees, such crates could stop compiling with any new compiler version. Since there's no field in Cargo.toml for the "maximum supported Rust version", one must manually find the last working nightly version. For this, I've written a small script to build a crate with a specific Rust version:

#!/bin/bash
cargo clean && rm -f Cargo.lock
rustup toolchain install $1 --profile minimal || exit
cargo update || exit
rustup run $1 cargo build
rustup toolchain uninstall $1 || exit

But overall, I'd say this is a non-issue.

5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.