`x.py dist` followed by `x.py build compiler/rustc` causes rustc to be rebuilt

[the8472]

Observed behavior:

$ ./x.py dist --stage 1
Updating only changed submodules
  Submodules updated in 0.00 seconds
Building rustbuild
    Finished dev [unoptimized] target(s) in 0.09s
Generating unstable book md files (x86_64-unknown-linux-gnu)
Building stage0 tool unstable-book-gen (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Building stage0 tool rustbook (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.11s
Rustbook (x86_64-unknown-linux-gnu) - unstable-book
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.14s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
Documenting standalone (x86_64-unknown-linux-gnu)
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.10s
Documenting book redirect pages (x86_64-unknown-linux-gnu)
Documenting stage1 std (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.15s
    Finished release [optimized] target(s) in 0.13s
    Finished release [optimized] target(s) in 0.16s
    Finished release [optimized] target(s) in 0.12s
    Finished release [optimized] target(s) in 0.12s
Documenting error index (x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.13s
Copying stage1 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)

[...]

Build completed successfully in 0:04:52


$ ./x.py build --stage 1 compiler/rustc
Updating only changed submodules
  Submodules updated in 0.01 seconds
Building rustbuild
    Finished dev [unoptimized] target(s) in 0.09s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
   Compiling jemalloc-sys v0.5.0+5.3.0
^C  Building [=======================> ] 239/242: jemalloc-sys(build)          

Expected behavior: The build should use the cached artifacts

Tested on b97bfc3

[jyn514]

This looks suspicious:

rust/src/bootstrap/builder.rs

Lines 723 to 727 in c396bb3

	// It seems that PlainSourceTarball somehow changes how some of the tools
	// perceive their dependencies (see #93033) which would invalidate fingerprints
	// and force us to rebuild tools after vendoring dependencies.
	// To work around this, create the Tarball after building all the tools.
	dist::PlainSourceTarball,

#93033

[jyn514]

Oh, this might just be because we create a .cargo/config.toml file that uses vendored sources? @the8472 if you delete .cargo, does it fix your issue? (Trying to test this locally, but cargo vendor is painfully slow unfortunately ...)

[jyn514]

I wasn't able to replicate this. (The vendoring changed in #97513; maybe that fixed it by accident?)

[jyn514]

@the8472 are you still running into this problem?

[RodBurman]

Over 3.5 years later and no more comments or reports of problems, does that mean we should close this issue?

[Kobzol]

No longer happens on main.