[Doc]: Added links to the `Target` section of the glossary for occurences of `target triple`
Fix for #11398. #11398 raises the concern that it isn't always abundantly clear in the cargo book, what a `target triple` (i.e. `x86_64-unknown-linux-gnu`) is. This is unfortunate, as it is well described in the [glossary](https://doc.rust-lang.org/cargo/appendix/glossary.html#target) of the cargo book (including the command on how to get all targets supported by `rustc`). To mitigate this problem I added links to the glossary entry for target triples to the sections where triples are referenced, but not enough information is given on what they are and how they look like.
feat: stabilize auto fix note
A note that some warnings could be fixed by running a `cargo fix` command was added in #10989 and made to work with `clippy` in #11399. It has only been turned on for `nightly` builds so far; this PR would make it show on `stable`.
The original motivation for making this note `nightly` only, was to [allow for iteration](https://github.com/rust-lang/cargo/issues/10976#issuecomment-1289297978) on the message output. There has yet to be any feedback on the message format in the time that it has been on `nightly`. This was brought up in a recent cargo team meeting and it was thought that we should move forward with showing this on `stable`.
close#10976
Disable network SSH tests on windows.
These tests have a high failure rate on Windows, so this disables them for now. I don't know exactly why they are failing. If I had to take a wild guess, I would suspect the use of WinCNG for the SSH backend, which may mean it is out of our control.
fix(toml): Add `default-features` to `TomlWorkspaceDependency`
In #11329 it was noted that `default-features` is ignored when used in a dependency that inherits from a workspace i.e.
```toml
[workspace]
members = []
[workspace.dependencies]
dep = "0.1"
[package]
name = "bar"
version = "0.2.0"
authors = []
[dependencies]
dep = { workspace = true, default-features = false }
```
This problem is caused by problems with deserializing a `TomlDependency` and not emitting an unused manifest key correctly. When discussed in a recent Cargo team meeting we felt the best course of action was to allow `default-features = false` when inheriting a dependency, but it does not change actually set `default-features`. It will be used to warn when there is a difference between the definition in `[workspace.dependencies]` and `[dependencies]` i.e.
```toml
[package]
name = "bar"
version = "0.2.0"
[dependencies]
dep = { workspace = true, default-features = false }
[workspace]
members = []
[workspace.dependencies]
dep = { version = "0.1", default-features = true }
```
This does not entirely resolve the problem with unused manifest keys. A follow up PR and issue will be created to address those concerns.
close#11329
Stabilize sparse-registry
### What does this PR try to resolve?
Stabilize `sparse-registry`
* Does not change the default protocol for accessing crates.io
### How should we test and review this PR?
Set environment variable `REGISTRIES_CRATES_IO_PROTOCOL=sparse` or set in `config.toml`:
```
[registries.crates-io]
protocol = 'sparse'
```
cc #9069
Wrapper type for data that should never be logged
Fixes#11519.
So far this is just creating the new wrapper type. If this looks okay, I'll start adding this wrapper in places where tokens and secret keys are held or passed.
Normalize git deps when doing `cargo vendor` for resolving deps inherited from a workspace
In #11192 it was noted that workspace inheritance causes vendored git dependencies to fail since `workspace = true` does not get resolved during vendoring.
To fix this, it was suggested to make `cargo vendor` work similar to `cargo package` since it resolves manifests before packaging them. I ended up implementing this proposed solution but sadly I could not find a way to share a ton of the code other than making a few things `pub`.
close#11192
Ignore `workspace.default-members` when running `cargo install` on root package of a non-virtual workspace
### What does this PR try to resolve?
* Fixes#11058
Two observable behaviors are fixed:
1. When running `cargo install` with `--path` or `--git` and specifically requesting the root package of a non-virtual workspace, `cargo install` will accidentally build `workspace.default-members` instead of the requested root package.
2. Further, if that `default-members` does not include the root package, it will install binaries from those other packages (the `default-members`) and claim they were the binaries from the root package! There is no way, actually, to install the root package binaries.
These two behaviors have the same root cause:
* `cargo install` effectively does `cargo build --release` in the requested package directory, but when this is the root of a non-virtual workspace, that builds `default-members` instead of the requested package.
### How should we test and review this PR?
I have included a test exhibiting this behavior. It currently fails in the manner indicated in the test, and passes with the changes included in this PR.
I'm not sure the solution in the PR is the _best_ solution, but the alternative I am able to come up with involves much more extensive changes to how `cargo install` works, to produce a distinct `CompileOptions` for every package built. I tried to keep the new workspace "API" `ignore_default_members()` as narrowly-scoped in its effect as possible.
### Additional information
The only way I could think this behavior change could impact someone is if they were somehow using `cargo install --path` (or `--git`) and wanting it to actually install the binaries from all of `default-members`. However, I don't believe that's possible, since if there are multiple packages with binaries, I believe cargo requires the packages to be specified. So someone would have to be additionally relying on specifying just the root package, but then wanting the binaries from more than just the root. I think this is probably an acceptable risk for merging!
Corrected documentation of how to cache binaries installed with `cargo install` in CI workflows
Fix for #11513. Updated the cargo book documentation on how to cache the `$CARGO_HOME` directory in CI workflows (added that the `.crates.toml` and `.crates2.json` files must be cached alongside the `/bin` folder, if installed binaries are cached)
Add network container tests
This adds some tests which use Docker containers to provide HTTPS and SSH servers. This should help with validating that Cargo's networking and security are working correctly. It can also potentially be used in the future for other tests that require more complex setups.
These tests are only run on Linux in CI. macOS does not have Docker there, and the Windows Docker does not support Linux containers. The tests should work on macOS if you run them locally with Docker Desktop installed. The SSH tests do not work on Windows due to issues with ssh-agent, but the HTTPS tests should work with Docker Desktop.
These tests require an opt-in environment variable to run:
* `CARGO_PUBLIC_NETWORK_TESTS=1` — This is for tests that contact the public internet.
* `CARGO_CONTAINER_TESTS=1` — This is for tests that use Docker.
Show progress of crates.io index update even `net.git-fetch-with-cli` option enabled
### What does this PR try to resolve?
This PR fixes#11574 .
### How should we test and review this PR?
Please run `cargo` with `net.git-fetch-with-cli` option enabled.
It should show `git fetch`'s progress output like below.
```
❯ CARGO_NET_GIT_FETCH_WITH_CLI=true ./target/debug/cargo b
Updating crates.io index
remote: Enumerating objects: 139821, done.
remote: Counting objects: 100% (2226/2226), done.
remote: Compressing objects: 100% (769/769), done.
receiving objects: 0% (1/139821)
```
fix(docs): add required "inherits" option to example profile
## What does this PR try to resolve?
I copy-pasted then modified the example [profile.<name>] section in Cargo's docs. I was met with the following error:
> error: profile quick-build-incremental is missing an inherits directive (inherits is required for all profiles except dev or release)
## How should we test and review this PR?
Copy-paste the new docs into a `Cargo.toml` file, tweak, then try to use the new profile (`cargo build --profile mynewprofile`).
## Additional information
None
Previous, `cargo metadata` allows a dependency with different renamed
co-exist. However, its `resolve.nodes.deps` will miss that dependency,
which is wrong. After this commit, `cargo metadata starts erroring out
for that situation.
This refactor reuse the logic of
`core::compiler::unit_dependencies::match_artifacts_kind_with_targets`
to emit error if there is any syntax error in `ArtifactKind`.
It also put `match_artifacts_kind_with_targets` to a better place `core::compiler::artifact`.
add documentation that SSH markers aren't supported
### What does this PR try to resolve?
Cargo doesn't support the ``@cert-authority`` or ``@revoked`` markers in SSH
Known Hosts files. The lines are silently ignored.
If a user is depending on these lines to connect to a Git server via
SSH, then their command line Git client will work, but Cargo will fail
with an error that the host key doesn't match.
This change adds a note explaining that Cargo doesn't support these
markers and suggests that the user change their cargo configuration to
fetch with the CLI client instead.
This PR fixes the first part (of 4) of the suggested tasks to fix#11577.
### How should we test and review this PR?
This change only modifies the Cargo book source. Running `mdbook build`
and checking the SSH Known Hosts section of the appendix on Git
authentication should be sufficient to test the PR.
### Additional information
The note in this section repeats what is said in the higher section on
SSH authentication, however given the recently implemented host key
checking, it seems worth calling out the limitation that Cargo doesn't
support these markers in the SSH known hosts file explicitly. Hopefully,
it reduces support requests and questions as well.
Cargo doesn't support the `@cert-authority` or `@revoked` markers in SSH
Known Hosts files. The lines are silently ignored.
If a user is depending on these lines to connect to a Git server via
SSH, then their command line Git client will work, but Cargo will fail
with an error that the host key doesn't match.
This change adds a note explaining that Cargo doesn't support these
markers and suggests that the user change their cargo configuration to
fetch with the CLI client instead.
Refs: #11577
Enable source_config_env test on Windows
This enables the `advaned_env::source_config_env` test on Windows. The issue with `Command` modifying the case of environment variables was fixed by https://github.com/rust-lang/rust/pull/85270.
Eric Huss
bors
jofas
Luca Barbato
Weihang Lo
Kyle Matsuda
Scott Schafer
Hayden Stainsby
hi-rustin
Matthew "strager" Glazar