Include path to rustc when generating package metadata

[cl91]

Currently, when generating package metadata to pass on to rustc in the form of -C metadata=, the path to rustc is not included. This means that a package compiled by different compilers will have the same metadata, other things being equal.

This is problematic when we are bootstrapping the Rust compiler with Cargo. Because Cargo generates the same metadata for both the stage1 and stage2 libraries, rustc will complain about multiple possible candidates of the same crate when using the stage1 compiler to compile the stage2 libraries.

We fix this by including the path to the rustc being used to compile the package when generating the package metadata. Because the stage1 and stage2 libraries are compiled by different compilers, this ensures that they come with different metadata.

This is also a good idea in general because you generally want to recompile a package when you switch compilers (although this doesn't happen outside bootstrapping the compiler itself).

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[cl91]

@alexcrichton

[alexcrichton]

For the bootstrap I was expecting usage of CARGO_TARGET_DIR as an environment variable to scope the output of the compiler, and that way you'd cache the results of stage1/stage2 without having to totally rebuild the world.

Taking the path into account feels a little sketchy to me as it doesn't correlate well to what version the compiler is except in the case of the bootstrap.

[cl91]

@alexcrichton I'd argue that because the whole point of bootstrapping is to recompile everything --- the standard library and the compiler crates, with the stage1 compiler, there is very little one can reuse by doing this. The only thing that does not need to be recompiled is the runtime libraries, ie rust_builtin and friends, jemalloc, and libbacktrace on Linux, which take less than 5 seconds in total to compile on even my slow laptop. The rest of the world must be recompiled by the stage1 compiler.

Moreover, due to the algorithm that rustc uses to load crates (in librustc/metadata/loader.rs), it is illegal to have multiple candidates (with the same metadata) of the same crate. It will be a compiler error if you try to compile the stage2 libraries with the stage1 compiler, without giving them a different set of metadata: the compiler will see two sets of libraries (one in the sysroot of the stage1 compiler, the other in the deps dir of the stage2 libraries being compiled) and complain about multiple candidates of the same crate.

The other option is to have an environment variable say CARGO_BOOTSTRAP_HASH and (if it exists) mix it into the package metadata. I can't say which approach is strictly better than the other, though the latter one does make the intention more obvious (that we need a different set of metadata because we are bootstrapping).

[alexcrichton]

there is very little one can reuse by doing this

This isn't quite true because I very often build a stage2 compiler but while I'm waiting on stage2 I'm testing with stage1. Each compiler is independent and can be useful in its own right.

[huonw]

r? @alexcrichton

[cl91]

This probably isn't a proper solution, so I'm closing it for now.