incr.comp.: Full re-use regression for unchanged code bases

[michaelwoerister]

A while ago we stopped getting full re-use when re-compiling an unchanged code base in the rust-icci tests:

• https://travis-ci.org/rust-icci/rand/jobs/198892096#L687
• https://travis-ci.org/rust-icci/euclid/jobs/201536795#L521
• https://travis-ci.org/rust-icci/rust-url/jobs/201184853#L419

The regression seems to have been introduced in this commit range, which includes the new graph reduction algorithm: 0648517...ea7a648

cc @nikomatsakis

[nikomatsakis]

Hmm, I am trying to reproduce this and so far I'm not succeeding. I see full re-use for rand at the given commit, at least, when using either the latest nightly or my local build (which is at the commit 3954c70). I'll take a look at the others.

[nikomatsakis]

One thing is that I am not seeing as many modules as the logs report. Perhaps I am not using the right set of switches.

[nikomatsakis]

The problem seems to be specific to crates that contain only generic items. In these cases, we get an empty serialized dep-graph. I think that, in the new representation, if there are literally no edges then we wind up never created the work-product nodes from last time, and hence we conclude they are dirty.

Roughly speaking the problem is that the second rustc run gets no re-use here:

lunch-box. rustc ~/tmp/foo.rs -Zincremental=$PWD/incr -Zincremental-info
incremental: 9840 nodes in dep-graph
incremental: 13341 edges in dep-graph
incremental: 0 edges in serialized dep-graph
incremental: 0 hashes in serialized dep-graph
incremental: re-using 0 out of 1 modules
lunch-box. rustc ~/tmp/foo.rs -Zincremental=$PWD/incr -Zincremental-info
incremental: session directory: 4 files hard-linked
incremental: session directory: 0 files copied
incremental: 9840 nodes in dep-graph
incremental: 13341 edges in dep-graph
incremental: 0 edges in serialized dep-graph
incremental: 0 hashes in serialized dep-graph
incremental: re-using 0 out of 1 modules
lunch-box. cat ~/tmp/foo.rs
#![crate_type="rlib"]
pub fn foo<T>() { }

[nikomatsakis]

Fix here: #40038