Failing to build cargo latest with cargo latest

[notdanilo]

Problem

   Compiling minimal-lexical v0.2.1
error: Unrecognized option: 'diagnostic-width'
                                                                                                                                                                                                               
error: could not compile `ff` (lib)
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo v0.82.0 (D:\dev\3rd\rust-lang\cargo)`, intermediate artifacts can be found at `D:\dev\3rd\rust-lang\cargo\target`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Steps

Run this twice on cargo's repository:

1. cargo install --debug --path . --force
2. cargo install --debug --path . --force

Possible Solution(s)

No response

Notes

No response

Version

$ cargo version --verbose
cargo 1.79.0 (ffa9cf99a 2024-06-03)
release: 1.79.0
commit-hash: ffa9cf99a594e59032757403d4c780b46dc2c43a
commit-date: 2024-06-03
host: x86_64-pc-windows-msvc
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:Schannel)
os: Windows 10.0.22631 (Windows 11 Professional) [64-bit]

[heisen-li]

@rustbot label +Command-install +A-building-cargo-itself

[weihanglo]

This is expected, as documented in the Cargo Contributor Guide.

But when cargo is not run via rustup, the toolchain may change based on the directory. Since Cargo changes the directory for each compilation, this can cause different calls to rustc to use different versions.

You can see under ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ff-0.13.0/rust-toolchain the ff crate has a quite old MSRV. It doesn't recognize a relatively new --diagnostic-width option from rustc.

The contributor guide also provides some workaround already. Setting RUSTC or RUSTUP_TOOLCHAIN might be good alternatives.

[weihanglo]

This is a gnarly problem that rustup and cargo are not a single binary, so Cargo doesn't know if it belongs to a toolchain. I don't think it is fixable at this moment, but leave this open for future reference.