Cargo doesn't rebuild package when changing local toolchains

[tgnottingham]

Problem

Cargo doesn't detect that it needs to do a fresh build when switching from one local toolchain to another, or when updating a local toolchain, at least under some circumstances.

Steps

(I haven't verified the correctness of the steps below, but they should give an idea of the issue.)

# Build rustc.
./x.py build library/std

# Create a toolchain from it.
cp -r build/x86_64-unknown-linux-gnu/stage1/ ../toolchains/toolchain-a
rustup toolchain link toolchain-a /path/to/toolchain-a

# Make a change to rustc code.

# Build rustc.
./x.py build library/std

# Create a toolchain from it.
cp -r build/x86_64-unknown-linux-gnu/stage1/ ../toolchains/toolchain-b
rustup toolchain link toolchain-b /path/to/toolchain-b

# Build something with toolchain-a, then try to build it with toolchain-b.
cd ..
cargo new foo
cd foo
cargo +toolchain-a build

# This does not build anything.
cargo +toolchain-b build

A similar issue occurs with just one toolchain, and you want to rebuild after updating it, though this is somewhat less surprising.

# Build rustc.
./x.py build library/std

# Create a toolchain from it.
cp -r build/x86_64-unknown-linux-gnu/stage1/ ../toolchains/toolchain-a
rustup toolchain link toolchain-a /path/to/toolchain-a

# Build something with toolchain-a.
cd ..
cargo new foo
cd foo
cargo +toolchain-a build

cd -

# Make a change to rustc code.

# Build rustc.
./x.py build library/std

# Update toolchain.
cp -r build/x86_64-unknown-linux-gnu/stage1/ ../toolchains/toolchain-a

cd -

# This does not build anything.
cargo +toolchain-a build

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.55.0 (32da73ab1 2021-08-23)
release: 1.55.0
commit-hash: 32da73ab19417aa89686e1d85c1440b72fdf877d
commit-date: 2021-08-23

[ehuss]

Thanks for the report! This is a consequence that cargo only triggers a rebuild if the version information from rustc -Vv changes, and that won't happen with local builds (note, there is an ignore-git option in config.toml, but that won't help in this case since the git version won't be changing if just changing files locally).

It is not clear to me if it is feasible to check something like the mtime of the rustc binary. That seems like it would have a high risk of disrupting development of rustc itself, though I can't think of how specifically.

[ehuss]

Coincidentally I am doing something with rustc right this moment where triggering rebuilds would be an issue. I'm making small changes to fix an error, and I don't want to trigger a full rebuild of the project each time I make change to rustc. It's a tricky issue to balance being aggressive on rebuilding on any change in the environment.

[Mark-Simulacrum]

It's probably a good idea to recommend/suggest -Zbinary-dep-dep for local (all?) toolchains, and there's been some movement on potentially stabilizing it. That should be mostly harmless and is what rustbuild always passes, so it should "just work".