This is another experiment for #9930.
Comparing preferring over exclusively using MSRV compatible:
Benefits
- Better error messages
- `--ignore-rust-version` is implicitly sticky
Downsides
- Can't backtrack for MSRV compatible version
- Still requires workspace-wide MSRV (compared to our desired end state of declaring MSRV as yet another dependency)
This builds on #12930
This fixes an issue where `--quiet` doesn't work with commands that have
subcommands. This is because `config_configure` only looks at the global
and top-level subcommand, and not deeper subcommands. The issue was that
`--quiet` was not defined as a global flag. This was changed in
https://github.com/rust-lang/cargo/pull/6358 in order to give a better
help message for `cargo test --quiet`. I don't remember if clap just
didn't support overriding at the time, or if we just didn't know how it
worked. Anyways, it seems to work to override it now, so I think it
should be fine to mark it as global.
This should bring in `--quiet` more in-line with how `--verbose` works.
This means that `--quiet` is now accepted with `cargo report`,
`cargo help`, and `cargo config`.
This also fixes `--quiet` with `cargo clean gc`.
This should also help with supporting `--quiet` with the new `cargo
owner` subcommands being added in
https://github.com/rust-lang/cargo/pull/11879.
Fixes#12957
feat(cli): Add '-n' to dry-run
This came from #12638 and my many small frustrations from wanting to use `-n` and not being able to.
We do not have any existing `-n` flags for this to be confused with.
I would wager that `-n` is such an entrenched short flag in build tools that it would not make sense for us to use it with any other flag.
For a survey of where `-n` is used as a short, see https://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table
This came from #12638 and my many small frustrations from wanting to use
`-n` and not being able to.
We do not have any existing `-n` flags for this to be confused with.
I would wager that `-n` is such an entrenched short flag in build tools that it would
not make sense for us to use it with any other flag.
For a survey of where `-n` is used as a short, see
https://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table
This mirrors some of the categories from `cargo help` (the man pages).
There are fewer categories to avoid extra vertical space. Instead, they
are left int the `Options` category but put first.
fix(add): Reduce the chance we re-format the user's `[features]` table
### What does this PR try to resolve?
#11743 pointed out that we re-format the users `[features]` table when running `cargo add` which was a bug introduced in #11099.
This reduces the chance people will run into this problem
- Reducing the scope of the `fmt` call
- Preserving formatting in a simple case
Actually removing the `fmt` case can make some common formatting cases more complex to do "right", so I'm punting on that for now.
### How should we test and review this PR?
Look at the individual commits as I show how each change improves the behavior of `cargo add`.
This is a carry-over from cargo-edit where we had to worry about the UX
of all of the behavior while now we are just relying on built-in cargo
behavior and don't need to test it specifically for `cargo add`.
On my machine, this test takes 11s.
This just gets rid of irrelevant packages in the registry. Looking into
which versions aren't needed would require a deeper pass, so I held off
on that for now.
Before, the tests were in the 300-500ms range and now they take
100-300ms.
This did call to my attention that `unrelated` is misspelled as
`unrelateed` but holding off on fixing that to reduce conflicts.
`cargo add` check `[dependencies]` order without considering the dotted item
### What does this PR try to resolve?
Try to close https://github.com/rust-lang/cargo/issues/11584
`cargo check` check `[dependencies]` order without considering the dotted item.
### How should we test and review this PR?
See the unit test.
This will only show the messaeg if we didn't already show a version req
with full precision specified ... mostly. We'll also skip it if its a
local or git dependency but we never show the version in those cases
because it doesn't matter.
The `precise_version` logic came from cargo-upgrade.
This gives a hint to users that we might not be showing the feature list
for the latest version but the earliest version.
Also when using a workspace dependency or re-using an existing
dependency, this is a good reminder of what the version requirement is
that was selected.
However, when the user or add (the common case) selected a full
precision requirement, this is redundant.
I'm also mixed on whether the meta version should show up.
Fixes#11073
This is done in the command, rather than in the op,
- To consistently construct the `Workspace`
- It is more composable as an API
A downside is we update the git dependencies a second time.
We are not rolling back on error.
- For some errors, the user might want to debug what went wrong
- Rollback adds its own complications and risks, including since its
non-atomic
Fixes#10901
This is prep for #10901 to avoid the most common failure case for the
lock file. We are assuming if the users action caused a change in the
manifes, then it will cause a change in the lock file. This isn't
entirely true but close enough and I think these semantics can make
sense.
