The tests were comparing rustc vs RUSTFLAGS which was obscuring the case
it was trying to test which was that different remaps shouldn't cause
different results.
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
`-Ztarget-applies-to-host --config target-applies-to-host=false` make it
possible to build two units for the same output directory with different
rustflags (one with artifact/target rustflags, one with none/host rust
flags). Those flags aren't included in the `-Cmetadata` hash which is
used to disambiguate different versions of crates, resulting in a conflict.
The actual error being produced appears to be the result of two invocations
of `rustc` racing and clobbering each other.
While we don't hash RUSTFLAGS because it may contain absolute paths that
hurts reproducibility, we track whether a unit's RUSTFLAGS is from host
config, so that we can generate a different metadata hash for runtime
and compile-time units.
We now include the prelude in so many places, this simplifies how we can
present how `cargo-test-support` works.
Yes, this included some `use` clean ups but its already painful enough
walking through every test file, I didn't want to do it twice.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
Enable propagating host rustflags to build scripts
### What does this PR try to resolve?
This PR primarily fixes#10206, but in doing so it also slightly modifies the interface for the unstable `target-applies-to-host` feature (#9453), and adds the unstable `target-applies-to-host-kind` flag to mirror `target-applies-to-host` for build scripts and other host artifacts.
The commit messages have more in-depth discussion.
### How should we test and review this PR?
The test case from #10206 now works rather than producing an error. It has also been added a regression test case. A few additional test cases have also been added to handle the expected behavior around rustflags for build scripts with and without `target-applies-to-host-kind` enabled.
### Additional information
1. This changes the interface for `target-applies-to-host` so that it does not need to be specified twice to be used. And it can still be set through configuration files using the `[unstable]` table. However, we may(?) want to pick a stable format for in-file configuration of this setting unless we intend for it to only ever be a command-line flag.
2. It may be that `target-applies-to-host-kind` is never behavior we want users to turn on, and that it should therefore simply be removed and hard-coded as being `false`.
3. It's not entirely clear how `target-applies-to-host-kind` should interact with `-Zmultitarget`. If, for example, `requested_kinds = [HostTarget, SomeOtherTarget]` and `kind.is_host()`, should `RUSTFLAGS` take effect or not? For the time being I've just hard-coded the behavior for single targets, and the answer would be "no".
This patch implements more complete logic for applying rustflags to
build scripts and other host artifacts. In the default configuration, it
only makes build scripts (and plugins and whatnot) pick up on
`rustflags` from `[host]`, which fixes#10206 but otherwise preserves
existing behavior in all its inconsistent glory. The same is the case if
`target-applies-to-host` is explicitly set to `false`.
When `target-applies-to-host` is explicitly set to `true`, rustflags
will start to be applied in the same way that `linker` and `runner` are
today -- namely they'll be applied from `[target.<host triple>]` and
from `RUSTFLAGS`/`build.rustflags` if `--target <host triple>` is given.
