doc: add `public` info in `cargo-add` man page.
### What does this PR try to resolve?
follow up https://github.com/rust-lang/cargo/pull/13046
add `public/private` explanation for `cargo-add` in man page.
### How should we test and review this PR?
### Additional information
The help info would be like this
- `cargo help add`
```
--public
Mark the dependency as public.
The dependency can be referenced in your library’s public API.
Unstable (nightly-only) <https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency>
--no-public
Mark the dependency as private.
While you can use the crate in your implementation, it cannot be referenced in your public API.
Unstable (nightly-only) <https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency>
```
- `cargo add -h`
```
--public Mark the dependency as public (unstable)
--no-public Mark the dependency as private (unstable)
```
- `cargo add --help`
```
--public
Mark the dependency as public (unstable)
The dependency can be referenced in your library's public API.
--no-public
Mark the dependency as private (unstable)
While you can use the crate in your implementation, it cannot be referenced in your public API.
```
Have cargo add --optional <dep> create a <dep> = "dep:<dep> feature
### What does this PR try to resolve?
`cargo add --optional <dep>` would create a `<dep> = "dep:<dep>` feature iff
- `rust-version` is unset or is new enough for the syntax
- `dep:<dep>` doesn't already exist
Fixes https://github.com/rust-lang/cargo/issues/11010
### How should we test and review this PR?
As the `dep:` syntax is only available starting with Rust 1.60. this pr maintains the previous usage convention in the earlier version.
run
```shell
cargo add --optional <dep>
```
with different rust-version to verify.
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.
