feat(install): Support `foo@version` like cargo-add
### What does this PR try to resolve?
This aims to make `cargo install` consistent with
- `cargo add foo@version` from #10472
- pkgid changes in #10582
- `cargo yank foo@version` from #10597
It also offers a shorthand for people installing a specific version.
### How should we test and review this PR?
#10582 acted as the FCP for this, see #10597
Documentation updates are split into their own commit to not clog up browsing the code.
Examine the tests to see if they make sense
### Additional information
While the `foo@vewrsion` syntax is the same, each's semantics are different. We had decided it was better to have the same syntax with different semantics than having the user worry about what syntax they use where. In `cargo install`s case, it has an
implicit-but-required `=` operand while `cargo-add` allows any operand.
This doesn't use the full `pkgid` syntax because that allows syntax that
is unsupported here.
This doesn't use `cargo-add`s parser because that is for version reqs.
I held off on reusing the parser from `cargo-yank` because they had
different type system needs and the level of duplication didn't seem
worth it (see Rule of Three).
fix typos found by the `typos-cli` crate
This fixes various typos inside `cargo`. They were found by [`typos-cli`](https://crates.io/crates/typos-cli). A few different typos were left out as they seemed either intentional or were needed. Typos found in `LICENSE-THIRD-PARTY` were left alone as well.
r? `@epage`
Fix use of .. in dep-info-basedir
### Summary
This allows setting, in .cargo/config's dep-info-basedir, some relative path that goes above the crate's directory.
### Motivation
In a setup like this:
```
repo_root
├── Makefile
├── some_c_things
│ └── foo.c
└── rust_things
├── Cargo.toml
└─── src
└── lib.rs
```
If you want the generated .d files to be includable directly in the Makefile (without post-processing), you need them to mention paths relative to the root, like:
rust_things/target/....: rust_things/src/lib.rs
### Implementation
For this you need to have relative paths with parent directories (in this case ..) in dep-info-basedir, which does not work without the change in this PR (due to render_filename doing only strip_prefix, while the basedir still contains literal ..s).
Let me know if this change is acceptable. Another implementation could be to canonicalize in ConfigRelativePath::resolve_path instead, especially since that struct outputs absolute paths. But that would have it access the filesystem, while it currently doesn't.
Move snapshot tests into testsuite
This moves all tests from the `snapshot` folder into the `testsuite` folder as described by [this comment](https://github.com/rust-lang/cargo/pull/10631#discussion_r866306441). A macro was also added so there is no need to specify the path in a `snapshot` test just the file. This was done for ease of refactoring and ease of porting new tests to `snapshot`
close#10627
r? `@epage`
When documenting private items in a binary, ignore warnings about links to private items
Previously, rustdoc would warn about linking to private items in a binary, even
though cargo unconditionally documents private items in a binary.
This changes cargo to silence the warning, since it's only relevant in
cases where the private items might not be documented.
Fixes https://github.com/rust-lang/rust/issues/89600.
Extend pkgid syntax with `@` support
In addition to `foo:1.2.3`, we now support `foo@1.2.3` for pkgids. We
are also making it the default way of rendering pkgid's for the user.
### What does this PR try to resolve?
With cargo-add in #10472, we've decided to only use ``@`` in it and to add
it as an alternative to `:` in the rest of cargo. `cargo-add`
originally used ``@`.` When preparing it for merge, I switched to `:` to
be consistent with pkgids. When discussing this, it was felt ``@`` has
precedence in too many tools to switch to `:` but that we should instead
switch pkgid's to use ``@`,` in a backwards compatible way. #10472 served
as the change proposal for this
See also
- https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024/26?u=epage
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Multiple.20ways.20of.20specifying.20versions
### How should we test and review this PR?
The focus of the testing is on the parsers unit tests and on the end-to-end output. We are not explicitly testing end-to-end input in this PR, assuming the unit tests are sufficient.
### Additional information
This only focuses on places we already accept pkgids. Looking into supporting `foo@1.2.3` in `cargo install` and `cargo yank` is being left for a future PR.
reorganize `snapshot` tests to better work in contexts that sort by extension
Changed snapshot file stricture from
```
<name>.in/
<name>.out/
<name>.stdout
<name>.stderr
```
To
```
<name>/in/
<name>/out/
<name>/stdout.log
<name>/stderr.log
```
This makes it easier to review and make changes when in contexts that sort by extension
close#10626
r? `@epage`
Add support for `-Zbuild-std` to `cargo fetch`
This allows downloading the dependencies for libstd in advance, which
can be useful in e.g. sandboxed build environments.
Fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/22.
r? `@ehuss`
This allows downloading the dependencies for libstd in advance, which
can be useful in e.g. sandboxed build environments.
- Abstract check for `--target` out into a function
- Try to abstract `test` special-casing into a function
This avoids hard-coding crate names in multiple places.
- Unify handling of checks for `--target` in `BuildConfig::new`
This makes sure it's checked consistently, without requiring each new command to check it explicitly.
- Share more code between `fetch` and `build` by adding `std_crates()`
- Warn about `--build-plan` and `-Zbuild-std` consistently, not just for `build`
Currently only `build` uses build-plan. But cargo may choose to add it to new commands in the future (e.g. check and doc).
Future-proof it, since it's simple to do.
Previously, rustdoc would warn about linking to items in a binary, even
though cargo unconditionally documents private items in a binary.
This changes cargo to silence the warning, since it's only relevant in
cases where the private items might not be documented.
This is something the existing test infrastructure supports, so I
figured I'd make it mirror it for snapbox. I'm mixed.
- It reads more like what a user would type, making it easier to run a
test locally or take a manual test case and automate it
- It can make it harder to parse the arguments when scanning tests
- Without using a crate like `shlex`, the syntax support is unclear
This was written for `cargo_add.rs`, based on `snapbox`. This allows
creating a test from a known reproduction case or easily debugging on an
existing test case.
In #10472, cargo-add was merged with support for an inline version
syntax of `foo@version`. That also served as the change proposal for
extending that syntax to `cargo install` for convinience and consistency.
While both commands are specifying a version-req, `cargo-install` has an
implicit-but-required `=` operand while `cargo-add` allows any operand.
This doesn't use the full `pkgid` syntax because that allows syntax that
is unsupported here.
This doesn't use `cargo-add`s parser because that is for version reqs.
I held off on reusing the parser from `cargo-yank` because they had
different type system needs and the level of duplication didn't seem
worth it (see Rule of Three).
Mark .cargo/git and .cargo/registry as cache dirs
Fixes#10457
### What does this PR try to resolve?
As we previously discussed in #10457 this marks `~/.cargo/git` and `~/.cargo/registry` as not to be included in backups, and not subject to content indexing. These directories can be fairly large and frequently changed, and should only contain content that can be re-downloaded if necessary.
### How should we test and review this PR?
I did two manual tests:
1. Using the binary built from this tree, run `cargo update` in a source tree that has a git dependency, and observe that afterwards, there is a `CACHEDIR.TAG` in `~/.cargo/git`.
2. Similarly, run `cargo update` and observe that there's a `CACHEDIR.TAG` in `~/.cargo/registry`.
(I ran this on Linux. This code should also trigger OS-specific behavior on macOS and Windows that's the same as is currently applied to `target/`.)
I added some test assertions.
