clap 3.1 renamed `App` to `Command`. When we upgrade to clap v4, the
lifetime will be removed and we can just use `clap::Command` instead of
a type alias. This is prep for that.
The `-Ztimings` option has existed for years, and many people use it to
profile and optimize their builds. It's one of the common reasons people
use nightly cargo.
The machine-readable JSON output may warrant further careful inspection
before we commit to a stable format. However, for the human-readable
output we don't need to make any commitment about the exact output.
Add a `--timings` option, as the stable equivalent to `-Ztimings`.
Stabilize the `html` output format, and require `-Zunstable-options` for
the `json` output format.
Document the new option, and update the testsuite.
Note: `cargo vendor --sync` did not use `multi_opt` and so it has both
multiple occurrences **and** multiple values. If we want to deprecate
this, we'll need `unstable-grouped` to be stablized (or pin our clap
version) and ensure each group has only 1 value.
- 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
This makes the following changes:
- Allows `cargo check`, `cargo fix`, and `cargo rustc` to support custom
named profiles. This retains the legacy behavior of those commands.
- Fixes `cargo bench` so that it supports custom named profiles.
cc rust-lang/rust#71249
This implements the Cargo side of 'Cargo report future-incompat'
Based on feedback from alexcrichton and est31, I'm implemented this a
flag `--future-compat-report` on `cargo check/build/rustc`, rather than
a separate `cargo describe-future-incompatibilities` command. This
allows us to avoid writing additional information to disk (beyond the
pre-existing recording of rustc command outputs).
This PR contains:
* Gating of all functionality behind `-Z report-future-incompat`.
Without this flag, all user output is unchanged.
* Passing `-Z emit-future-incompat-report` to rustc when
`-Z report-future-incompat` is enabled
* Parsing the rustc JSON future incompat report, and displaying it
it a user-readable format.
* Emitting a warning at the end of a build if any crates had
future-incompat reports
* A `--future-incompat-report` flag, which shows the full report for
each affected crate.
* Tests for all of the above.
At the moment, we can use the `array_into_iter` to write a test.
However, we might eventually get to a point where rustc is not currently
emitting future-incompat reports for any lints. What would we want the
cargo tests to do in this situation?
This functionality didn't require any significant internal changes to
Cargo, with one exception: we now process captured command output for
all units, not just ones where we want to display warnings. This may
result in a slightly longer time to run `cargo build/check/rustc` from
a full cache. since we do slightly more work for each upstream
dependency. Doing this seems unavoidable with the current architecture,
since we need to process captured command outputs to detect
any future-incompat-report messages that were emitted.
The implementation now follows `rustc --print <INFO>` and adds the
`--print <INFO>` option to the `cargo rustc` subcommand. When the `cargo
rustc --print <INFO>` command is executed, all extra arguments are
passed to the `rustc --print <INFO>` command including the
Cargo-specific (compiler) target flags and options from Cargo's
configuration and environment variables. If multiple `--target <TRIPLE>`
options are used, then the list is of (compiler) targets are iterated
and outputed with an empty line delimiting the output for each compiler
target. If no `--target <TRIPLE>` is used, then the host compiler target
is used.
None of the output is altered. It is just a straight dump of the `rustc
--print <FOO>` command.
This implementation works with any of the `<INFO>` values for the `rustc
--print <FOO>` command, i.e. `cfg`, `target-list`, `sysroot`, etc.
Most of the arguments for either `cargo rustc` are ignored unles
recognized by the `rustc --print <FOO>` argument. For
example, `--target <TRIPLE>`. Cargo configuration is target dependent,
so the `--target <TRIPLE>` must be recognized.
The `--print-cfg` flag will be replaced with the `--print foo` option
and passed to `rustc --print foo`. The output will be the "raw" output
from the `rustc --print foo` command instead of a serialized JSON of the
RustcTarget Data. This is the first step in changing the implementation.
The serialization code is no longer needed.
The `--cfg` flag is changed to `--print-cfg`, so it is a little more
obvious what the flag will do. At the same time, the implementation is
changed to only affect the `cargo rustc` subcommand. It skips
downloading the entire crate graph and compiling/building the project.
Instead, it just obtains the rustc target data similar to the
`ops::compile` function and then returns. The `ops::print_cfg` function
is added, but this could also be moved to just the `cargo rustc`
subcommand.
Similar to the `--unit-graph` flag, which is also hidden, the `--cfg`
and `--rustc-cfg` are hidden. I think they will be made visible once the
feature is stablized.
The `--cfg` option is changed to `--rustc-cfg` for the build, bench,
test, and check subcommands but left as `--cfg` for the rustc
subcommand. The `--rustc-cfg` flag is more descriptive of
configuration (cfg) that will be printed as JSON, but it looks weird if
`--rustc-cfg` is used with the rustc subcommand, i.e.:
```pwsh
PS C:\>cargo rustc --rustc-cfg
```
versus
```
PS C:\>cargo rustc --cfg
```
By using the rustc subcommad, the type of output and configuration is
known, but wiht the other subcommands it is ambiguous what a lone
`--cfg` would output.
The `--cfg` flag is added to the `cargo rustc` subcommand. The
implementation generally follows the `--unit-graph` implementation in
that it aborts compilation after the build context is created.
I discovered that cargo runs the `rustc --print cfg` every time it
builds/compiles a package. It stores this information for all compiler
targets and the host in the `RustcTargetData` struct, which is further
populated when the build context is created. When the `rustc --print
cfg` command is ran internally, all of the Cargo configurations and
environment variables are applied to the command. This means that the
command does not need to be re-run for the `--cfg` flag. Instead, I just
needed to print what was already populated into the `RustcTargetData`
struct for the build context and abort before executing the
build/compile job.
The existence of the `rustc --print cfg` command being executed
internally to Cargo also meant that multi-target and cross-compilation
are naturally supported. However, the output kind of has to be JSON
because it is not possible to select a single compiler target to print.
It gets messy very quickly if multiple targets are specified and which
one to use for the "human" output similar to the `rustc --print cfg`
command. The solution is to output in JSON like the `--unit-graph` flag
and include the data for the host and any specified targets. A
downstream parser can then pull out/extract the target data that is
needed.
The `--cfg` flag needs to be added to the `cargo build` subcommand, too.
The `--unit-graph` flag is available in both subcommands and so should
the `--cfg` flag for consistency. Ultimately, the `cargo build`
subcommand "calls" the `cargo rustc` subcommand. In other words, both
subcommands use the same implementation.
The flag does not appear in the help text, but the `--unit-graph` does
not either. I need to work on this as well.
The `anyhow` crate interoperates with the `std::error::Error` trait
rather than a custom `Fail` trait, and this is the general trend of
error handling in Rust as well.
Note that this is mostly mechanical (sed) and intended to get the test
suite passing. As usual there's still more idiomatic cleanup that can
happen, but that's left to later commits.
To preserve old `profile` behavior, some cases of `--profile`
should not trigger an error. Plus, the 'check' profile should be
allowed for profile selection tests and `rustc --profile=check`.
This allows creating custom profiles that inherit from other profiles.
For example, one can have a release-lto profile that looks like this:
[profile.release-lto]
inherits = "release"
lto = true
The profile name will also carry itself into the output directory name
so that the different build outputs can be cached independently from
one another.
So in effect, at the `target` directory, a name will be created for
the new profile, in addition to the 'debug' and 'release' builds:
```
$ cargo build --profile release-lto
$ ls -l target
debug release release-lto
```
- Fix: `cargo test --all-targets` was running lib tests three times.
- `--all-targets` help strings were wrong or misleading.
- Minor cleanup to add `Proposal` type to maybe make the code more readable.
Ed Page
Weihang Lo
Jon Gjengset
Josh Triplett
hi-rustin
Eric Huss
Aaron Hill
Chris Field
Dirkjan Ochtman
KaneGreen
Alex Crichton
Dan Aloni
Dan Aloni
Collins Abitekaniza
Damian
Dale Wijnand