Dropping unused and unreferenced external crate should not trigger recompile

[mqudsi]

After compiling a project that has a reference to an external crate in Cargo.toml but that is not imported (no extern crate foo;), a subsequent cargo build after dropping the unused dependency from Cargo.toml triggers a full rebuild.

Unless the removal triggers a change in the version of a different dependency in the lock file (which I don't think can currently happen in this scenario), a recompile should be skipped.

(I'd even go further and say that a remote crate imported with extern crate foo or even #[macro_use] extern crate foo; that is not actually used and does not introduce build scripts, etc. should also not trigger a rebuild, but that is at least understandable as it can affect type negotiations, etc. in which case it should be more of an "early abort" once the AST has been formed and it becomes possible to determine that no types have changed.)

[nagisa]

Cargo has no concept of unused dependencies. For incremental-enabled builds, rustc should definitely notice there has been no change, and I think it does work as expected in that respect (but I haven’t checked).

cc @michaelwoerister

[pnkfelix]

discussed in today's meeting. We agree with @nagisa 's comment above: We cannot really implement the feature as described (i.e. we cannot avoid invoking rustc for this scenario), but also, the rustc invocation should be fast in incremental mode.

So we just need to test that it is fast in incremental mode.