"cargo clean; cargo build" doesn't save work w/ incremental

[nikomatsakis]

In fixing #34991, I tried an experiment of doing cargo build then cargo clean and cargo build with incremental compilation enabled. I believe that, in principle, this ought to enable full-reuse, since the sources haven't changed. It did not. It's worth making a small cargo package and experimenting with why this might be the case (or maybe even small standalone rustc program, though we do see reuse in specific examples).

[hanna-kruppe]

I needed a double take when reading the title, so for clarification: You put the incr.comp. directory outside of target/ and only used cargo clean to force invoking rustc again? Eventually, when inc.comp. works and is integrated in the usual work flow, its cache will be cleared by cargo clean, right?

[nikomatsakis]

@rkruppe yes, that is correct.

[nikomatsakis]

Hmm, it's not as simple as getting "no re-use". For example, I tried the deque package and got these print outs:

incremental: re-using 6 out of 6 modules (libc)
incremental: re-using 3 out of 13 modules (rand)
incremental: re-using 1 out of 1 modules (deque)

that's 50% reuse :) granted, it ought to be 100%, but still -- pretty neat.

[nikomatsakis]

A further note: if I just execute the command to rebuild rand, I get 100% reuse. So it's something to do w/ building libc first.

[nikomatsakis]

Problem is that the metadata hashes are changing (unsurprisingly, but also reassuringly).

[nikomatsakis]

hmm so I realize that we are computing metadata hash by iterating over the dep-nodes, but the ordering of that iteration is almost certainly not stable.

[nikomatsakis]

I just confirmed that this is indeed the problem. Have to think about the best way to sort the nodes.