List available packages if providing `--package` with an empty value
May resolves#8591
## How
First we need to take the responsibility of check command line arguments from claps. I've examine all 10 build commands and all of them call [`ArgMatchesExt::compile_options`](2f115a76e5/src/cargo/util/command_prelude.rs (L389-L395)) directly or indirectly. And `compile_options` [calls `check_optional_opts`](2f115a76e5/src/cargo/util/command_prelude.rs (L499-L501)) to check if target selection options given an empty value. So we can do the same logic there.
I've also add a error message for an edge case though that one would never trigger at this moment.
This commit refactors the internals of Cargo to no longer have a
singular `--target` flag (and singular `requested_target` kind throught)
but to instead have a list. The semantics of multiple `--target` flags
is to build the selected targets for each of the input `--target` flag
inputs.
For now this is gated behind `-Zmultitarget` as an unstable features,
since I'm not entirely sure this is the interface we want. In general
it'd be great if we had a way to simply specify `Unit` structures of
what to build on the CLI, but we're in general very far away from that,
so I figured that this is probably sufficient at least for testing for
now.
cc #8156
Add `cargo tree` command.
This migrates [cargo-tree](https://github.com/sfackler/cargo-tree/) into Cargo as a built-in command. This is based on a recent master (4108d216ec), and should be mostly similar in functionality. There are a variety changes:
* `--all-targets` renamed to `--no-filter-targets` to avoid confusion with the `--all-targets` flag used in other Cargo commands with a different meaning.
* `--all`/`-a` renamed to `--no-dedupe` to avoid confusion with the `-all` flag which means "all workspace crates" in other Cargo commands.
* `--duplicate` renamed to `--duplicates` (with alias), just a personal preference.
* Added support for multiple roots (workspace support).
* Added the `--graph-features` flag for including features in the graph (to "explain" why a feature is enabled).
* Added `{f}` to format string to show features.
* Handles new feature resolver.
* Handles cyclical dev dependencies.
* Added a test suite.
* Dropped the dependency on petgraph, in favor of a simpler custom graph.
Closes#7286.
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.
This suite of tests verifies various cases around the 'inherits'
keyword, and also verifies the relationship between profile overrides
and custom profiles.
Cargo has of #7143 enabled pipelined compilation by default which
affects how the compiler is invoked, especially with respect to JSON
messages. This, in some testing, has proven to cause quite a few issues
with rustbuild's current integration with Cargo. This commit is aimed at
adding features to Cargo to solve this issue.
This commit adds the ability to customize the stream of JSON messages
coming from Cargo. The new feature for Cargo is that it now also mirrors
rustc in how you can configure the JSON stream. Multiple
`--message-format` arguments are now supported and the value specified
is a comma-separated list of directives. In addition to the existing
`human`, `short`, and `json` directives these new directives have been
added:
* `json-render-diagnostics` - instructs Cargo to render rustc
diagnostics and only print out JSON messages for artifacts and Cargo
things.
* `json-diagnostic-short` - indicates that the `rendered` field of rustc
diagnostics should use the "short" rendering.
* `json-diagnostic-rendered-ansi` - indicates that the `rendered` field of rustc
diagnostics should embed ansi color codes.
The first option here, `json-render-diagnostics`, will be used by
rustbuild unconditionally. Additionally `json-diagnostic-short` will be
conditionally used based on the input to rustbuild itself.
This should be enough for external tools to customize how Cargo is
invoked and how all kinds of JSON diagnostics get printed, and it's
thought that we can relatively easily tweak this as necessary to extend
it and such.
Import the cargo-vendor subcommand into Cargo
This commit imports the external [alexcrichton/cargo-vendor
repository][repo] into Cargo itself. This means it will no longer be
necessary to install the `cargo-vendor` subcommand in order to vendor
dependencies. Additionally it'll always support the latest feature set
of Cargo as it'll be built into Cargo!
All tests were imported as part of this commit, but not all features
were imported. Some flags have been left out that were added later in
the lifetime of `cargo vendor` which seem like they're more questionable
to stabilize. I'm hoping that they can have separate PRs adding their
implementation here, and we can make a decision of their stabilization
at a later date.
The current man page for `cargo vendor -h` will look like:
cargo-vendor
Vendor all dependencies for a project locally
USAGE:
cargo vendor [OPTIONS] [--] [path]
OPTIONS:
-q, --quiet No output printed to stdout
--manifest-path <PATH> Path to Cargo.toml
--no-delete Don't delete older crates in the vendor directory
-s, --sync <TOML>... Additional `Cargo.toml` to sync and vendor
--respect-source-config Respect `[source]` config in `.cargo/config`
-v, --verbose Use verbose output (-vv very verbose/build.rs output)
--color <WHEN> Coloring: auto, always, never
--frozen Require Cargo.lock and cache are up to date
--locked Require Cargo.lock is up to date
-Z <FLAG>... Unstable (nightly-only) flags to Cargo, see 'cargo -Z help' for details
-h, --help Prints help information
ARGS:
<path> Where to vendor crates (`vendor` by default)
This cargo subcommand will vendor all crates.io and git dependencies for a
project into the specified directory at `<path>`. After this command completes
the vendor directory specified by `<path>` will contain all remote sources from
dependencies specified. Additionally manifest beyond the default one can be
specified with the `-s` option.
The `cargo vendor` command will also print out the configuration necessary
to use the vendored sources, which when needed is then encoded into
`.cargo/config`.
Since this change is not importing 100% of the functionality of the
existing `cargo vendor` this change does run a risk of being a breaking
change for any folks using such functionality. Executing `cargo vendor`
will favor the built-in command rather than an external subcommand,
causing unimplemented features to become errors about flag usage.
[repo]: https://github.com/alexcrichton/cargo-vendor
This commit imports the external [alexcrichton/cargo-vendor
repository][repo] into Cargo itself. This means it will no longer be
necessary to install the `cargo-vendor` subcommand in order to vendor
dependencies. Additionally it'll always support the latest feature set
of Cargo as it'll be built into Cargo!
All tests were imported as part of this commit, but not all features
were imported. Some flags have been left out that were added later in
the lifetime of `cargo vendor` which seem like they're more questionable
to stabilize. I'm hoping that they can have separate PRs adding their
implementation here, and we can make a decision of their stabilization
at a later date.
The current man page for `cargo vendor -h` will look like:
cargo-vendor
Vendor all dependencies for a project locally
USAGE:
cargo vendor [OPTIONS] [--] [path]
OPTIONS:
-q, --quiet No output printed to stdout
--manifest-path <PATH> Path to Cargo.toml
--no-delete Don't delete older crates in the vendor directory
-s, --sync <TOML>... Additional `Cargo.toml` to sync and vendor
--respect-source-config Respect `[source]` config in `.cargo/config`
-v, --verbose Use verbose output (-vv very verbose/build.rs output)
--color <WHEN> Coloring: auto, always, never
--frozen Require Cargo.lock and cache are up to date
--locked Require Cargo.lock is up to date
-Z <FLAG>... Unstable (nightly-only) flags to Cargo, see 'cargo -Z help' for details
-h, --help Prints help information
ARGS:
<path> Where to vendor crates (`vendor` by default)
This cargo subcommand will vendor all crates.io and git dependencies for a
project into the specified directory at `<path>`. After this command completes
the vendor directory specified by `<path>` will contain all remote sources from
dependencies specified. Additionally manifest beyond the default one can be
specified with the `-s` option.
The `cargo vendor` command will also print out the configuration necessary
to use the vendored sources, which when needed is then encoded into
`.cargo/config`.
Since this change is not importing 100% of the functionality of the
existing `cargo vendor` this change does run a risk of being a breaking
change for any folks using such functionality. Executing `cargo vendor`
will favor the built-in command rather than an external subcommand,
causing unimplemented features to become errors about flag usage.
[repo]: https://github.com/alexcrichton/cargo-vendor
This is part of https://github.com/rust-lang/rust/issues/44663
This implements the 'frontend' portion of RFC 1977. Once PRs
https://github.com/rust-lang/rust/pull/59335 and
https://github.com/rust-lang/crates.io/pull/1685 are merged,
it will be possible to test the full public-private dependency feature:
marking a dependency a public, seeing exported_private_dependencies
warnings from rustc, and seeing pub-dep-reachability errors from Cargo.
Everything in this commit should be fully backwards-compatible - users
who don't enable the 'public-dependency' cargo feature won't notice any
changes.
Note that this commit does *not* implement the remaining two features of
the RFC:
* Choosing smallest versions when 'cargo publish' is run
* Turning exported_private_dependencies warnings into hard errors when
'cargo publish' is run
The former is a major change to Cargo's behavior, and should be done
in a separate PR with some kind of rollout plan.
The latter is described by the RFC as being enabled at 'some point in
the future'. This can be done via a follow-up PR.
