x.py in incremental mode still rebuilds stage0-rustc if stage0-std changed.

[eddyb]

That is, stage0-rustc appears to lose incremental artifacts.
cc @alexcrichton @Mark-Simulacrum

[Mark-Simulacrum]

Yes, I believe this is because rustc/cargo will otherwise error on "found a new std" or something like that? I don't quite see how incremental is different from the normal compilation here?

[eddyb]

@Mark-Simulacrum incremental would still work even if dependencies changed.
I think the fundamental problem here is that x.py deletes everything, whereas cargo clean (which, IIRC, does not remove incremental artifacts by default) would be appropriate.

[Mark-Simulacrum]

Hm, I thought cargo clean was equivalent to rm -rf target essentially -- @alexcrichton could you clarify that? Would it be better to use cargo clean in rustbuild?

[alexcrichton]

Regardless of what cargo clean does I don't think we should execute it here. Rustbuild is overly conservative in what it deletes, and it can get away probably with just deleting the deps folder instead of the entire folder. That would leave around the incremental cache.

I believe, however, that cargo clean is like rm -rf target

[eddyb]

Maybe the cargo clean benchmarks I remember @nikomatsakis having for incremental had the incremental dir elsewhere than target.

I sure was confused by it, since I'd expect cargo clean to remove all artifacts.
If it does do that, then I agree x.py should just remove a subset of the contents of target dirs.

[eddyb]

Looking at the code, these clear_if_dirty calls appear to be relevant:

rust/src/bootstrap/builder.rs

Lines 758 to 786 in d99a320

	match mode {
	Mode::Std => {
	self.clear_if_dirty(&my_out, &self.rustc(compiler));
	},
	Mode::Test => {
	self.clear_if_dirty(&my_out, &libstd_stamp);
	},
	Mode::Rustc => {
	self.clear_if_dirty(&my_out, &self.rustc(compiler));
	self.clear_if_dirty(&my_out, &libstd_stamp);
	self.clear_if_dirty(&my_out, &libtest_stamp);
	},
	Mode::Codegen => {
	self.clear_if_dirty(&my_out, &librustc_stamp);
	},
	Mode::ToolBootstrap => { },
	Mode::ToolStd => {
	self.clear_if_dirty(&my_out, &libstd_stamp);
	},
	Mode::ToolTest => {
	self.clear_if_dirty(&my_out, &libstd_stamp);
	self.clear_if_dirty(&my_out, &libtest_stamp);
	},
	Mode::ToolRustc => {
	self.clear_if_dirty(&my_out, &libstd_stamp);
	self.clear_if_dirty(&my_out, &libtest_stamp);
	self.clear_if_dirty(&my_out, &librustc_stamp);
	},
	}

The problem is that the directory my_out refers to is non-trivially structured.

Instead of removing $my_out/*, we need to remove all the files (or at least the ones that are artifacts) and the deps directory in $my_out{/$target,}/{release,debug}/.

[eddyb]

I keep hitting this, specifically it keeps rebuilding rustc_codegen_llvm and rustdoc, every time I change rustc, which cause them to take much longer than any of the rustc crates, and this issue has become my main bottleneck (now that I'm building on a -j48 machine).

[eddyb]

Nominating for discussion (specifically, allocating resources towards this) at the next relevant team meeting (tagged both @rust-lang/infra and @rust-lang/compiler, as I'm not sure which has "jurisdiction" here).

[Mark-Simulacrum]

It'd be helpful to know how much rustbuild can "trust" the compiler here. Can we keep incremental artifact directories around from previous versions of the compiler?

[michaelwoerister]

The compiler can only work with incremental artifacts that it created itself. For any other version of the compiler it has to assume that it's incompatible. It usually just ignores such incompatible artifacts, but in the bootstrapping scenario, it might not always be smart enough to do that.

[Zoxc]

I think the question here is will rustc's incremental artifacts correctly deal with crates changing (including adding and removing crates) in the sysroot. If so, we could keep the incremental folder around. Cargo assumes the sysroot is unchanging, which is why we remove the target directory in the first place.

[eddyb]

Incremental doesn't care about --extern vs -L, so I'd expect it to be pretty resilient here.

[pnkfelix]

triage: P-medium. (this inefficiency in incremental comp. would be nice to resolve, but is not P-high IMO.)