Fix env/cfg set for cargo test and cargo run.

[ehuss]

There are some situations where a build script may need to run multiple times for the same package during the same cargo session. There was a bug in that some of the values in the Compilation struct didn't handle this case. The solution here is to be more careful about how this extra data is associated with Units, instead of assuming a package's build script only runs once.

The things that were not being handled properly:

• Compilation::extra_env, which is the output of cargo:rustc-env in build scripts. The solution here is to use the Metadata hash which is used elsewhere for distinguishing build script outputs.
• Compilation::cfgs, which is the output of cargo:rustc-cfg in build scripts and the features to be set, and this is only used for doctests. The solution here is to just add those --cfg flags directly in the Doctest struct.

The situations that cause a build script to be run multiple times:

• A package needed for both the host and target. In the test here, this was accomplished with a proc-macro (which has to be host) and a cyclical dev dependency, but there are many other ways to trigger this.
• Something built with different features (with the new feature resolver), usually due to host/target differences.
• Something built with different profile settings, usually due to host/target differences.

Fixes #9100

[rust-highfive]

r? @Eh2406

(rust-highfive has picked a reviewer for you, use r? to override)

[ehuss]

I changed this to just be keyed off the Metadata to simplify things. I don't remember why I originally included PackageId, as the PackageId hash is already included in the Metadata. If we are uncomfortable with the possibility of a hash collision, I can switch it back, or we can consider using a stronger hash (like siphash 128?).

[ehuss]

I was also wondering if we should update the documentation for how environment variables are set for cargo test and cargo run. Perhaps just a note that says certain environment variables (such as cargo:rustc-env) are also set for running executables for cargo test and cargo run, but that it is not recommended to rely on that since it ties the executable to Cargo's execution environment? Or maybe just leave it undocumented?

[alexcrichton]

Looks good to me, thanks!

I think it makes sense to go ahead and document this but discourage usage. We've already got users depending on it (probably accidentally?) so I don't think that we can change it anyway. If you'd prefer to do doc updates in a future PR that's ok too, r=me on this regardless.

[ehuss]

Ok, I added a small note. Thanks Alex! 😄

@bors r=alexcrichton

[bors]

📌 Commit 1607a68 has been approved by alexcrichton

[bors]

⌛ Testing commit 1607a68 with merge 3875bbb...

[bors]

☀️ Test successful - checks-actions
Approved by: alexcrichton
Pushing 3875bbb to master...