Improve CI caching by skipping mtime checks for paths in $CARGO_HOME
Skip mtime checks for paths pointing into `$CARGO_HOME` to avoid rebuilds when only caching $CARGO_HOME/registry/{index, cache} and $CARGO_HOME/git/db and some of the dependencies have `rerun-if-changed=directory` in their `build.rs`
I considered skipping mtime checking only on `$CARGO_HOME/registry/src` but it looks like other functionality (like downloading a newer version of dependency) is unaffected by this and this way we also cover the same issue with git based dependencies (except the part where `cargo` is forced to re-fetch submodules if `$CARGO_HOME/git/checkouts` is missing) and it is more in line with the discussion in #9455Fix#11083
Credit `@weihanglo` for the test (I did add a case of checking that dependency update still triggers a rebuild but they are the original author of the rest of the test)
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
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
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!
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)
```
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`.
chore: Fix typos
Seeing several typo PRs, like #11560, I figured I'd run my source code spell checker on cargo to help catch a lot of these earlier, in one big batch.
Support vendoring with different revs from same git repo
### What does this PR try to resolve?
Fixes#10667
### How should we test and review this PR?
test case is included
fix: deduplicate dependencies by artifact target
### What does this PR try to resolve?
In cases when a compile target is specified for a bindep and the crate depending on it, cargo fails to deduplicate the crate dependencies and attempts to build the dependent crate only once with non-deterministic feature set, which breaks e.g. https://github.com/rvolosatovs/musl-bindep-feature-bug
Fix the issue by including the optional artifact compile target in the `Unit` in order to avoid wrongfully deduplicating the dependent crates
Fixes https://github.com/rust-lang/cargo/issues/11463
Fixes https://github.com/rust-lang/cargo/issues/10837
Fixes https://github.com/rust-lang/cargo/issues/10525
Note, that this issue is already accounted for by `cargo`, but in different context a similar situation can occur while building the build script, which:
1. may be built for different target than the actual package target
2. may contain dependencies with different feature sets than the same dependencies in the dependency graph of the package itself
That's why this PR is simply reusing the existing functionality for deduplication
### How should we test and review this PR?
Build https://github.com/rvolosatovs/musl-bindep-feature-bug
### Additional information
This is based on analysis by `@weihanglo` in https://github.com/rust-lang/cargo/issues/10837#issuecomment-1339365374
I experimented with adding the whole `UnitFor` to the internal unit struct, but that seems unnecessary.
It would probably be nicer to refactor `IsArtifact` and instead turn it into a 3-variant enum with a possible compile target, but I decided against that to minimize the diff. Perhaps it's worth a follow-up?
Add warning if potentially-scrapable examples are skipped due to dev-dependencies
### What does this PR try to resolve?
Another point of feedback I've received on the scrape-examples feature is that the dev-dependency situation is quite confusing and subtle. To make users more aware of the issue, I added a warning where Cargo will alert users when examples are skipped due to a dev-dependency requirement, along with proposing a fix.
### How should we test and review this PR?
The test `docscrape::no_scrape_with_dev_deps` has been updated to reflect this new warning.
r? `@weihanglo`
(PS thank you for the reviews Weihang. I know I'm doing lots of little patches right now to get this feature finalized. If you want to share the reviewing burden on scrape-examples with anyone else, let me know!)
Don't scrape examples from library targets by default
### What does this PR try to resolve?
Based on some [early feedback](https://www.reddit.com/r/rust/comments/zosle6/feedback_requested_rustdocs_scraped_examples/) about the scrape-examples feature, both documentation authors and consumers did not consider examples useful if they are scraped from a library's internals, at least in the common case. Therefore this PR changes the default behavior of `-Zrustdoc-scrape-examples` to *only* scrape from example targets, although library targets can still be configured for scraping.
### How should we test and review this PR?
I have updated the `docscrape` tests to reflect this new policy, as well as the Unstable Options page in the Cargo book.
r? `@weihanglo`
Stabilize terminal-width
This stabilized the passing of the `--diagnostic-width` flag to rustc and rustdoc so that they will format diagnostics to fit within the terminal size. Previously they always assume the width is 140. The diagnostics are trimmed with `...` to elide parts of extra-long lines.
In cases where the width isn't known (such as not when used on a tty, or with mintty), then cargo does not pass the flag and the default of 140 is still used.
At this time there is no way for the user to override the width (unlike with the progress bar width). That can be added in the future if there is demand. https://github.com/rust-lang/rust/issues/84673#issuecomment-1179096971 contains some thoughts on some different ideas.
Closes https://github.com/rust-lang/rust/issues/84673
