This takes the most surgical, direct route to addressing the problem.
Alternatively, we could look into why `cargo rustc` and `cargo check`
are different.
Fixes#15493
It turns out, running `cargo rustc --print cfg -Zunstable-options` (and
the like, https://github.com/rust-lang/cargo/issues/9357) fail with
`.cargo/config.toml` setups like
```toml
[build]
# custom target json that lives in `./targets/my-super-cool-target.json`
target = "my-super-cool-target"
[env]
RUST_TARGET_PATH = { value = "./targets", relative = true }
```
resulting in
```
❯ cargo rustc --print cfg -Zunstable-options
error: Error loading target specification: Could not find specification for target "my-super-cool-target". Run `rustc --print target-list` for a list of built-in targets
error: process didn't exit successfully: `C:\Users\lukas\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin\rustc.exe --target my-super-cool-target --print cfg` (exit code: 1)
```
The reason for that is that cargo recognizes the target from the
`.cargo/config` and then implicitly passes that along to the spawned
rustc process, but it does so without passing along the important
environment that is required for the target tuple to make sense.
(can add a test if desired, just tell me where)
This was always enabled on nightly since 1.83-nightly (2024-09).
We have no feedback since then, so assume it is a low-impact change.
This stabilization is targeted at 1.85 (2025-02-20)
Previously `cargo rustc -- <flags>` got a lower precedence than
some of the flags set by cargo internal.
This is a bit unintuitive as Cargo generally treats user-provided
CLI flags with the highest priority.
This commit changes `cargo rustc -- <flags>` to a higher precedence:
higher than most of flags set by Cargo, and only lower than
`build.rustflags` family.
Unsure if this affects people's workflow, so this behavior is only
enabled on nightly for collectin feedback. A environment variable
`__CARGO_RUSTC_ORIG_ARGS_PRIO=1` is provided for users to opt-out.
If everything goes well, the nightly gate will be removed after a
few of releases.
See discussion on https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/rustflags.20precendence.20of.20.60cargo.20rustc.60
According to the documentation the --crate-type flag accepts a comma
separated list of crate types. However, these are never actually
split into individual items and passed verbatim to rustc.
Since cargo fails to associate cases such as 'staticlib,cdylib' to
a specific crate type internally, it has to invoke rustc to determine
the output file types for this unknown crate type, which returns only
the first file type of the first crate type in the list. Consequently
cargo will be looking only for a single '.a' artifact on Linux to be
copied to the target directory.
Fix this by splitting the list of provided crate types into individual
items before further processing them.
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.
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.
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
It was unnecessary to pass `spilt-debuginfo` if there is no debuginfo.
Tests are touched here only for matching rustflags invocation stderr
in the original test suite.
- One parser change found by `cargo_config::includes` is that clap 2
would ignore any values after a `=` for flags.
`cargo config --show-origin` is a flag but the test passed `--show-origin=yes` which
happens to give the desired result for that test but is the same as
`--show-origin=no` or `--show-origin=alien-invasion`.
- The parser now panics when accessing an undefined attribute but clap
takes advantage of that for sharing code across commands that have
different subsets of arguments defined. I've extended clap so we can
"look before you leap" and put the checks at the argument calls to
start off with so its very clear what is tenuously shared. This
allows us to go in either direction in the future, either addressing
how we are sharing between commands or by moving this down into the
extension methods and pretending this clap feature doesn't exist
- On that topic, a test found clap-rs/clap#3263. For now, there is a
hack in clap. Depending on how we fix that in clap for clap 4.0, we
might need to re-address things in cargo.
- `value_of_os` now requires setting `allow_invalid_utf8`, otherwise it
asserts. To help catch this, I updated the argument definitions
associated with lookups reported by:
- `rg 'values?_os' src/`
- `rg 'values?_of_os' src/`
- clap now reports `2` for usage errors, so we had to bypass clap's
`exit` call to keep the same exit code.
BREAKING CHANGE: API now uses clap3
The `with_stdout_contains` was mis-used. Since some lines may or may not
appear for some compiler targets and environments (nightly, beta,
stable, etc.) the tests would fail because the output was not identical.
Instead of a using raw strings, each line with the arch, endian, env,
family, vendor, pointer_width, etc. that are known to always be
present (at least of the CI builds) are included. This should work for
the CI environments and my local environment.
The `panic="unwind"` appears in the output for the CI tests, but not in
my local tests. I need to investigate the origin of this configuration
but it causes the CI builds to fail.
A `.cargo/config.toml` file is used to add the "crt-static" target
feature and test printing the compiler target configuration contains the
`target_feature="crt-static"` line.
The `RUSTFLAGS` environment variable is used to add the "crt-static"
target feature and test printing the target compiler configuration
contains the `target_feature="crt-static"` line.
This commit is the Cargo half of support necessary for
rust-lang/rust#70458. Today the compiler emits embedded bytecode in
rlibs by default, but compresses it. This is both extraneous disk space
and wasted build time for almost all builds, so the PR in question there
is changing rustc to have a `-Cembed-bitcode` flag which, when enabled,
places the bitcode in the object file rather than an auxiliary file (no
extra compression), but also enables `-Cembed-bitcode=no` to disable
bitcode emission entirely.
This Cargo support changes Cargo to pass `-Cembed-bitcode=no` for almost
all compilations. Cargo will keep `lto = true` and such working by not
passing this flag (and thus allowing bitcode to get embedded), but by
default `cargo build` and `cargo build --release` will no longer have
any bitcode in rlibs which should result in speedier builds!
Most of the changes here were around the test suite and various
assertions about the `rustc` command lines we spit out. One test was
hard-disabled until we can get `-Cembed-bitcode=no` into nightly, and
then we can make it a nightly-only test. The test will then be stable
again once `-Cembed-bitcode=no` hits stable.
Note that this is intended to land before the upstream `-Cembed-bitcode`
change. The thinking is that we'll land everything in rust-lang/rust all
at once so there's no build time regressions for anyone. If we were to
land the `-Cembed-bitcode` PR first then there would be a build time
regression until we land Cargo changes because rustc would be emitting
uncompressed bitcode by default and Cargo wouldn't be turning it off.
