The proper fix is in https://github.com/Byron/gitoxide/releases/tag/gix-v0.41.0
which unfortunately can't be used as it also comes with the latest `tempfile` v3.4
which causes other issues when compiling on some platforms.
Thus we first disable the flaky tests, and re-enable them with the `gix` upgrade
which should be possible once `tempfile` doesn't hinder `cargo` on some platforms
anymore.
Related to https://github.com/rust-lang/cargo/issues/11821
Add `CARGO_PKG_README`
Fixes#11597
This environment variable shows the path to the README file of your package. From #11597:
> Cargo may rewrite the package’s `Cargo.toml` and move the README file around, relative to the manifest. I would like to `include_str!()` this README in my `lib.rs`, but am unable to do so right now, because if I specify `include_str!("../../README")` it works for development, but I can’t package my crate. Conversely if I specify `include_str!("../README")` it works when packaged, but not during development.
Adding display of which target failed to compile
Closes#10834
Attached example.zip is the same as the one mentioned on the issue. You could use it to test the fix by using the new built cargo:
```./cargo build --manifest-path C:\Rust\example_cargo_error\Cargo.toml```
Before fixing:
```
error: could not compile `example` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
```
After fixing:
```
error: could not compile `example` (build script) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
```
[example.zip](https://github.com/rust-lang/cargo/files/10522342/example.zip)
Fix `CARGO_CFG_` vars for configs defined both with and without value
When a rustc cfg is defined both with and without value, the environment variable should provide all the values. Before this change, it ended up being empty.
Fixes: #11789
When a rustc cfg is defined both with and without value, the
environment variable should provide all the values. Before this change,
it ended up being empty.
Fixes: #11789
Make `sparse` the default protocol for crates.io
Changes the default protocol for accessing crates.io to `sparse`.
The protocol can be switched back to `git` via the configuration key `registries.crates-io.protocol` = `git`
Closes#10965
This allows to use `gitoxide` for all fetch operations, boosting performance
for fetching the `crates.io` index by a factor of 2.2x, while being consistent
on all platforms.
For trying it, nightly builds of `cargo` can specify `-Zgitoxide=fetch`.
It's also possible to set the `__CARGO_USE_GITOXIDE_INSTEAD_OF_GIT2=1` environment
variable (value matters), which is when `-Zgitoxide=none` can be used
to use `git2` instead.
Limitations
-----------
Note that what follows are current shortcomings that will be addressed in future PRs.
- it's likely that authentication around the `ssh` protocol will work differently in practice
as it uses the `ssh` program.
- clones from `file://` based crates indices will need the `git` binary to serve the locatl repository.
- the progress bar shown when fetching doesn't work like the orgiinal, but should already feel 'faster'.
patch can conflict on not activated packages
### What does this PR try to resolve?
In the resolver there is a data structure called a `conflicting_activations`, which records all the reasons a "better" version was not picked for the package being resolved. Normally, these are packages that are currently active that for one reason or another block one of the other versions. Several optimizations assumed that this was always true, even going so far as to use `.expect`. This was a mistake because when there's a `patch` involved there can be conflicts on a version that is not selected. So the correct behavior is to fall back to skip the optimizations and try all versions when a `conflicting_activations` are not active.
### How should we test and review this PR?
This adds two automated tests based on the reproductions in #7463 and #11336. So the test suite now covers this case. It can also be tested by reconstructing the repositories originally reported in those issues.
### Additional information
It could be that in the long term the correct fix is to figure out how to support patch without having a conflicting activation that is not activated. But that would be a much bigger change. And for now this assumption is only used in optimizations, so this gets people unstuck.
fix(toml): Provide a way to show unused manifest keys for dependencies
Dependencies have not been able to show unused manifest keys for some time, this problem partially resulted in #11329.
This problem is caused by having an `enum` when deserializing. To get around this you can use:
```rust
#[serde(flatten)]
other: BTreeMap<String, toml::Value>,
```
This collects any unused keys into `other` that can later be used to show warnings. This idea was suggested in a thread I cannot find but is mentioned in [serde#941](https://github.com/serde-rs/serde/issues/941).
Improve error for missing crate in --offline mode for sparse index
This changes sparse registries to instead return `NotFound` when a non-cached crate is requested in `--offline` mode.
The resolver can then suggest removing the `--offline` flag if resolution fails, which is a more helpful error than the one currently issued: `attempting to make an HTTP request, but --offline was specified`.
With this change, the behavior matches what is already done for git-based registries.
Closes#11276
This changes sparse registries to instead return not found when a non-cached crate is requested in offline mode.
The resolver can then suggest removing the --offline flag if resolution
fails.
feat(resolver): `-Zdirect-minimal-versions`
This is an alternative to `-Zminimal-versions` as discussed in #5657.
Problems with `-Zminimal-versions` includes
- Requires the root most dependencies to verify it and we then percolate that up the stack. This requires a massive level of cooperation to accomplish and so far there have been mixed results with it to the point that cargo's unstable
documentation discourages its use.
- Users expect `cargo check -Zminimal-versions` to force resolving to minimal but it doesn't as the default maximal resolve is compatible and requires `cargo update -Zminimal-versions`
- Different compatible versions might be selected, breaking interop between crates, changing feature unification, and breaking `-sys` crates without bad `links`
`-Zdirect-minimal-versions` instead only applies this rule to your
direct dependencies, allowing anyone in the stack to immediately adopt
it, independent of everyone else.
Special notes
- Living up to the name and the existing design, this ignores yanked
crates. This makes sense for `^1.1` version requirements but might
look weird for `^1.1.1` version requirements as it could select
`1.1.2`.
- This will error if an indirect dependency requires a newer version.
Your version requirement will need to capture what you use **and** all
of you dependencies. An alternative design would have tried to merge
the result of minimum versions for direct dependencies and maximum
versions for indirect dependencies. This would have been complex and
led to weird corner cases, making it harder to predict. I also suspect
the value gained would be relatively low as you can't verify that
version requirement in any other way.
- This also means discrepancies between `dependencies` and `dev-dependencies` are errors
- The error could be improved to call out that this was from minimal
versions but I felt getting this out now and starting to collect
feedback was more important.
One advantage of this approach over `-Zminimal-versions` is that it removes most of the problems that [cargo-minimal-versions](https://github.com/taiki-e/cargo-minimal-versions) tried to workaround.
As for the implementation, this might not be the most elegant solution but it works and we can always iterate and improve on it in the future.
- We keep the state as a `bool` throughout but compensate for that by explicitly creating a variable to abstract away constants
- The name changes depending on the context, from `direct_minimal_version` when dealing with the unstable flag to `first_minimal_version` when the concept of "direct" is lost to `first_version` when we split off the ordering concept into a separate variable
- Packages that respect `direct_minimal_versions` are determined by whether they are the top-level `summaries` that get past into `resolve`
### What does this PR try to resolve?
The primary use case is verifying version requirements to avoid depending on something newer than might be available in a dependent
For this to help the MSRV use case, the crate author must directly depend on all indirect dependencies where their latest release has too new of an MSRV but at least they can do so with the `^` operator, rather than `<` and breaking the ecosystem.
### How should we test and review this PR?
The first two commits add tests using `-Zminimal-versions`. The commit that adds `-Zdirect-minimal-versions` updates the tests, highlighting the differences in behavior.
### Additional information
Potential areas of conversation for stablization
- Flag name
- Handling of yanked (pick first non-yanked, pick yanked, error)
- Quality of error message
- Should the package have a "memory" of this flag being set by writing it to the lockfile?
Potential future work
- Stablize this
- Remove `-Zminimal-versions`
- Update `cargo publish`s `--verify` step to use this.
- The challenge is this won't be using the packaged `Cargo.lock` which probably should also be verified.
Error message for transitive artifact dependencies with targets the package doesn't directly interact with
Address #11260. Produces an error message like described by `@weihanglo` [here](https://github.com/rust-lang/cargo/issues/11260#issuecomment-1400455203):
```
error: could not find specification for target "x86_64-windows-msvc"
Dependency `bar v0.1.0` requires to build for target "x86_64-windows-msvc".
```
Note that this is not a complete fix for #11260.
Suggest cargo add when installing library crate
### What does this PR try to resolve?
When using `cargo install` instead of `cargo use` the error message is the following:
```
error: there is nothing to install in `foo v0.0.1`, because it has no binaries
`cargo install` is only for installing programs, and can't be used with libraries.
To use a library crate, add it as a dependency in a Cargo project instead.
```
It would be good to suggest to the user to use `cargo add`.
### How should we test and review this PR?
The `no_binaries` test from `tests/testsuite/install.rs` covers that case.
Switch some tests from `build` to `check`
#11341 brought up issues with cargo's `testsute` size and speed. One of the suggested fixes was switching most tests to `check` instead of `build`. This PR did that.
Before size on `nightly`: 4.4GB
After size on `nightly`: 4.2GB
Regex to find `build` in `tests/testsuite`: `cargo\(".*build.*\)`
Before: 1607
After: 626
Note I did not remove all `build` I only did the easy ones that required minimal changes. I also tried not to touch systems I was unsure about. There could be other uses of `build` I missed as well.
I still need to play around with `opt-level`, `debug=0`, and a few other tweaks, but there should be more time/memory to drop.
Each test file changed is in a commit of its own, so you should look commit by commit.
* moved `is_empty` check into `check_token`
* improved error message (is quite long now but should explain the error
well)
* removed one helper function from new test
When using registry operations with authentication there will be now an
error if the given token is not valid.
This is a technically a breaking change because a registry might give
some tokens which will be denied by these new checks.
In practice these tokens cause issues with HTTP so no registry should
generate them.
This is an alternative to `-Zminimal-versions` as discussed in #5657.
The problem with `-Zminimal-versions` is it requires the root most
dependencies to verify it and we then percolate that up the stack. This
requires a massive level of cooperation to accomplish and so far there
have been mixed results with it to the point that cargo's unstable
documentation discourages its use.
`-Zdirect-minimal-versions` instead only applies this rule to your
direct dependencies, allowing anyone in the stack to immediately adopt
it, independent of everyone else.
Special notes
- Living up to the name and the existing design, this ignores yanked
crates. This makes sense for `^1.1` version requirements but might
look weird for `^1.1.1` version requirements as it could select
`1.1.2`.
- This will error if an indirect dependency requires a newer version.
Your version requirement will need to capture what you use **and** all
of you dependencies. An alternative design would have tried to merge
the result of minimum versions for direct dependencies and maximum
versions for indirect dependencies. This would have been complex and
led to weird corner cases, making it harder to predict. I also suspect
the value gained would be relatively low as you can't verify that
version requirement in any other way.
- The error could be improved to call out that this was from minimal
versions but I felt getting this out now and starting to collect
feedback was more important.
Extend the existing CARGO_BIN_NAME environment variable to be set when
building binary example targets, additional to "normal" binary targets.
Closes#11689.
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
Deny warnings in CI, not locally
### What does this PR try to resolve?
The problem with #![deny(warnings)] is it makes iteration more difficult as you might have intermediate states with warnings. Its slightly better that we defer this to cargo test --lib but that still means you can't run a subset of tests against your experiment until you've cleaned up all of your warnings. This can lead to users [working around the problem which could accidentally slip in](d92d04840c).
### How should we test and review this PR?
The first round for this PR includes a warning in the `cargo` crate to ensure it breaks CI. It will then be reverted.
### Additional information
See also https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.60.23!.5Bcfg_attr.28test.2C.20deny.28warnings.29.29.5D.60
Add '-C' flag for changing current dir before build
This implements the suggestion in #10098 to make cargo change cwd before
completing config processing and starting the build. It is also an
alternative to `--manifest-path` that resolves the issue described
in #2930.
The behavior of this new flag makes cargo build function exactly the same when run at the root of the project as if run elsewhere outside of the project. This is in contrast to `--manifest-path`, which, for example, results in a different series of directories being searched for `.cargo/config.toml` between the two cases.
Fixes#10098
Reduces impact of #2930 for many, possibly all impacted, by switching to this new cli argument.
### How should we test and review this PR?
The easiest way to reproduce the issue described in #2930 is to create an invalid `.cargo/config.toml` file in the root of a cargo project, for example `!` as the contents of the file. Running cargo with the current working directory underneath the root of that project will quickly fail with an error, showing that the config file was processed. This is correct and expected behavior.
Running the the same build with the current working directory set outside of the project, e.g. /tmp, and passing the `--manifest-path /path/to/project/Cargo.toml`. The build will proceed without erroring as a result of reading the project's `.cargo/config.toml`, because config file searching is done from cwd (e.g. in `/tmp` and `/`) without including the project root, which is a surprising result in the context of the [cargo config documentation](https://doc.rust-lang.org/cargo/reference/config.html), which suggests that a `.cargo/config.toml` file checked into the root of a project's revision control will be processed during the build of that project.
Finally to demonstrate that this PR results in the expected behavior, run cargo similar to the previous run, from /tmp or similar, but instead of `--manifest-path /path/to/project/Cargo.toml`, pass `-C/path/to/project` to cargo (note the missing `Cargo.toml` at the end). The build will provide the exact same (expected error) behavior as when running it within the project root directory.
### Additional information
~Passing a path with a trailing '/' will result in failure. It is unclear whether this is a result of improper input sanitization, or whether the config.cwd value is being improperly handled on output. In either case this needs to be resolved before this PR is merge-ready.~
(the above issue appears to have been a side effect of local corruption of my rustup toolchain, and unrelated to this change)
Because a `struct Config` gets created before command line arguments are processed, a config will exist with the actual cwd recorded, and it must then be replaced with the new value after command line arguments are processed but before anything tries to use the stored cwd value or any other value derived from it for anything. This change effectively creates a difficult-to-document requirement during cargo initialization regarding the order of events. For example, should a setting stored in a config file discovered via cwd+ancestors search be wanted before argument processing happens, this could result in unpleasant surprises in the exact use case this feature is being added to fix.
A long flag was deferred out to not block this on deciding what to name it. A follow up issue will be created.
This implements the suggestion in #10098 to make cargo change cwd before
completing config processing and starting the build. It is also an
alternative to --manifest-path that resolves the issue described
in #2930.
When running `cargo doc -Zrustdoc-scrape-example`, it performs
additional type checks that a plain old `cargo doc` doesn't.
That leads to some extra failure when adopting scrape-example for docs.rs.
In de34d60 we introduced `unit_can_fail_for_docscraping` in order to
make `-Zrustdoc-scrape-example` not fail whenever `cargo doc` builds.
Build script executions were accidentally included in the list of
fallible units. A plain `cargo doc` does fail when a build script
fails. `-Zrustdoc-scrape-example` should follow that.
Any directory entry ending with `.rs`, including directories, were
previously assumed to be files, and could end up as targets.
Now only regular files and symbolic links are inferred.
Turn off debuginfo for build dependencies v2
This PR is an alternative to #10493, fixing its most important issue: the unit graph optimization to reuse already built artifacts for dependencies shared between the build-time and runtime subgraphs is preserved (most of the time).
By deferring the default debuginfo level in `dev.build-override` until unit graph sharing, we check whether re-use would happen. If so, we use the debuginfo level to ensure reuse does happen. Otherwise, we can avoid emitting debuginfo and improve compile times (on clean, debug and check builds -- although reuse only happens on debug builds).
I've kept the message explaining how to bump the debuginfo level if an error occurs while running a build script (and backtraces were requested) that was in the previous PR.
I've ran benchmarks on 800 crates, at different parallelism levels, and published the (surprisingly good) results with visualizations, summaries, and raw data [here](https://github.com/lqd/rustc-benchmarking-data/tree/main/experiments/cargo-build-defaults).
Opening this PR as discussed in [Eric's message](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Defaults.20for.20faster.20compilation.20of.20.22for.20host.22.20units/near/304236576l) as draft since 2 tests won't pass. That fixes the `cargo-crev` case we saw as a blocker last time, but doesn't fix all such cases of reuse, like the 2 failing tests:
- [`optional_build_dep_and_required_normal_dep`](642a0e625d/tests/testsuite/build_script.rs (L4449))
- and [`proc_macro_ws`](bd5db301b0/tests/testsuite/features2.rs (L1051))
These failures make sense, since the debuginfo optimization is done during traversal, it depends on the contents of the unit graph. These tests ensure that sharing happens even on finer-grained invocations: respectively, with an optional shared dependency that is later enabled, and building shared dependencies by themselves first and later as part of a complete workspace build.
In both these situations, there is no unit that is shared in the graph during the first invocation, so we do the optimization and remove the debuginfo. When the graph changes in the following invocation, sharing is present and we have to build the shared units again with debuginfo.
These cases feel rarer than `cargo-crev`'s case, but I do wonder if there's a way to fix them, or if it's acceptable to not support them.
This test dynamically enables a shared build/runtime dependency, and
therefore doesn't trigger the build/runtime sharing reuse optimization,
as the build dep is initially built without debuginfo for optimization
purposes.
Add some assertions to ensure that debuginfo is not used to compile
build dependencies, in a way that differs between the old and new
defaults: some of the assert elision could match the previous defaults
with debuginfo. These new assertions break if `-C debuginfo` is present
in the commands cargo ran.
Make cargo install report needed features
### What does this PR try to resolve?
The problem described in issue #11617 where cargo tells the user, that no binaries are available
because of the chosen features, but does not tell which features could be enabled to fix the
situation.
Fixes#11617.
### How should we test and review this PR?
Try to cargo install a crate, where all binaries need some features enabled, without enabling
the features and check the error message.
The test suite already contains tests for this.
This enum will be used to model the current Option<u32> value in
profiles, as the explicitly set value, and also allow to model a
deferred value: one that can be ignored for optimization purposes,
and used in all other cases.
This allows to have a default debuginfo for build dependencies, that can
change:
- if a dependency is shared between the build and runtime subgraphs, the
default value will be used, to that re-use between units will
continue.
- otherwise, a build dependency is only used in a context where
debuginfo is not very useful. We can optimize build times in this
situation by not asking rustc to emit debuginfo.
Make cargo aware of dwp files.
When using -Csplit-debuginfo=packed on Linux, rustc will produce a dwp file. Unlike the dwo files, whose paths are embedded into the binary, there's no information in the binary to help a debugger locate a dwp file. By convention, the dwp file for `<EXE>` is given the name `<EXE>.dwp` and placed next to `<EXE>`.
When cargo hardlinks the executable file rustc put in target/debug/deps into target/debug, it also needs to hardlink the dwp file along with it. Failing to do this prevents the debugger from finding the dwp file when the binary is executed from target/debug, as there's no way for the debugger to know to look in the deps subdirectory.
The split_debuginfo option is passed down into file_types to make this possible. For cargo clean manual handling is added to match the other split_debuginfo files. bin_link_for_target also passes in None because it won't care about the dwp file.
refactor(toml): Move `TomlWorkspaceDependency` out of `TomlDependency`
**This should not be merged until after #11409**
In #11523 it was noted that you could use `{}.workspace = true` in `[patch.{}]`, but it would cause a panic. This panic was caused by an oversight on my part when implementing [workspace inheritance](https://github.com/rust-lang/rfcs/blob/master/text/2906-cargo-workspace-deduplicate.md). Before this PR any field that had the type `TomlDependency` could specify `{}.workspace = true` and `cargo` would allow it to be a `TomlWorkspaceDependency`. While it could be `TomlWorkspaceDependency` it would never be resolved since only:
> Dependencies in the `[dependencies]`, `[dev-dependencies]`, [`build-dependencies]`, and `[target."...".dependencies]` sections will support the ability to reference the `[workspace.dependencies]` definition of dependencies.[^1]
This PR makes it so that only those fields can pull from `[workspace.dependencies]`, while still sharing `TomlDependency` everywhere it is needed. It does this by making `MaybeWorkspace` generic over both `Defined` and `Workspace`, then moving `TomlWorkspaceDependency` out of `TomlDependency` and into a `MaybeWorkspace` that the correct fields can use.
[^1]: [rfc2906-new-dependency-directives](https://github.com/rust-lang/rfcs/blob/master/text/2906-cargo-workspace-deduplicate.md#new-dependency-directives)
Closes: #11523
`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.
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)
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`.
When using -Csplit-debuginfo=packed on Linux, rustc will produce a dwp file.
Unlike the dwo files, whose paths are embedded into the binary, there's no
information in the binary to help a debugger locate a dwp file. By convention,
the dwp file for <EXE> is given the name <EXE>.dwp and placed next to <EXE>.
When cargo hardlinks the executable file rustc put in target/debug/deps into
target/debug, it also needs to hardlink the dwp file along with it. Failing to
do this prevents the debugger from finding the dwp file when the binary is
executed from target/debug, as there's no way for the debugger to know to look
in the deps subdirectory.
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
Use workspace lockfile when running `cargo package` and `cargo publish`
### What does this PR try to resolve?
Fix#11148.
### How should we test and review this PR?
Please run the integration test in `tests/testsuite/publish_lockfile.rs` or try the steps from the issue.
