Cargo can't update itself when new Rust editions are released and its dependencies update to use them

[adamnovak]

Problem

I have rustc 1.50.0 (cb75ad5db 2021-02-10) and cargo 1.50.0 (f04e7fab7 2021-02-04). This Cargo is old, and I would like to upgrade it to the next version.

I think reported version 1.50.0 is really crate version 0.50.0, so let me just install the next minor release:

cargo install cargo --version ^0.51 --force
    Updating crates.io index
  Installing cargo v0.51.0
error: failed to compile `cargo v0.51.0`, intermediate artifacts can be found at `/tmp/cargo-installqEM1Fi`

Caused by:
  failed to download `once_cell v1.15.0`

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `/home/anovak/.cargo/registry/src/github.com-1ecc6299db9ec823/once_cell-1.15.0/Cargo.toml`

Caused by:
  failed to parse the `edition` key

Caused by:
  this version of Cargo is older than the `2021` edition, and only supports `2015` and `2018` editions.

Cargo is not able to update itself, I think because its dependencies have released new versions which match version specifiers higher in the dependency tree, and the dependency resolver isn't considering whether the current version of Cargo (or even rustc) will be able to use the versions it is selecting.

Steps

1. Have Cargo 1.50.0 and Rustc 1.50.0
2. Try to use Cargo to install the next version of Cargo (cargo install cargo --version 0.51.0 --force)
3. Observe failure due to Cargo not being able to understand the dependencies of the next version of itself.

Possible Solution(s)

The dependency resolver could backtrack when it downloads a dependency and finds it requires an unavailable edition or otherwise has an un-parse-able manifest. The registry could record what editions or versions of Cargo or Rust a crate release is compatible with, and Cargo could use that information to avoid trying to install things it cannot handle.

Notes

Python's pip understands that some releases of some packages only work on some versions of Python, and uses this information when selecting dependency versions to install.

Version

cargo 1.50.0 (f04e7fab7 2021-02-04)
release: 1.50.0
commit-hash: f04e7fab73128592a4063983c302da788bdfaba5
commit-date: 2021-02-04

[Eh2406]

Cargo is only intended to work with the version of Rust it shipped with. You cannot use Cargo to install a newer version of Cargo. If you want to update you'll need follow the instructions from the place you installed it. If you installed using rustup then rustup update will work. If you installed some other way you'll need to check their documentation.

Whether in general cargo should downgrade your dependencies to match the outdated version of Rust you are using is an interesting design question, hinging on how much capacity the community has for maintaining older versions of libraries. This question has been discussed at length in a number of venues. It is not clear what the correct solution is. https://rust-lang.github.io/rfcs/2495-min-rust-version.html is an accepted suggestion for at least improving the error messages when that is the source of the problem.

[adamnovak]

Thanks for clearing that up @Eh2406.

I didn't even want to update Cargo today, I just wanted to use my Rust 1.50 to build a 2018 edition package, from a tag tagged before the 2021 edition even existed. Because I'm trying to use Rust and Emscripten together, and for that to work I need rustc and emcc to have been built with compatible LLVM versions, and I had a version combination that seemed to work.

But Cargo was going and trying to use 2021 edition versions of the transitive dependencies of the package I was trying to build. I fixed that by updating rustc and Cargo, but that I have upgraded both, I need to check to make sure I can still use this version of Emscripten. And when edition 2022 or whatever comes out, the whole thing might break again.

Is there something the package author should have done when they released the package (like make a lockfile?) that would have prevented it from not being able to build anymore on a Cargo/rustc version combination that used to be able to build it? Do I need to get the project I am trying to build to rid its dependency tree of packages that do not properly declare an MSRV?

[epage]

Is there something the package author should have done when they released the package (like make a lockfile?) that would have prevented it from not being able to build anymore on a Cargo/rustc version combination that used to be able to build it? Do I need to get the project I am trying to build to rid its dependency tree of packages that do not properly declare an MSRV?

Normally cargo will fail and tell you what package had failed for MSRV and you can then use cargo update --precise to set your lockfile to a specific version.

#10623 is one issue with but we can't time travel to fix old versions, unfortunately.

There has been talk of an MSRV-aware resolver and other solutions to improve the MSRV situation. I don't have the various links at the moment to point to.

[Eh2406]

cargo install ... --locked tells cargo to use the versions from the lockfile in the crate instead of downloading the most recent version. The versions in lockfile are probably out of date, but have a high probability of working well together, and with Cargo/Rust from when it was published. Of course this only works if the publish happened with the version of cargo recent enough to include the lock file. See the problems with time travel mentioned above.