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.
Although `CompileKind::is_host` is currently used for build dependencies prior
to unit graph sharing, it's not a guarantee. So we use `UnitFor::is_for_host`
to make detection more future-proof.
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.
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.
Avoid saving the same future_incompat warning multiple times
### What does this PR try to resolve?
Each time a build, that causes future_incompat warnings, is run, a report about each
warning is created and saved to disk with a new id quicky filling up the JSON file. This PR
adds a check if the report is already on disk and avoids saving a new instance of it.
Fixes#11594.
### How should we test and review this PR?
Perform a build that gives one or more future_incompat warnings, and see that they
are added to the JSON file only once when the build is repeated.
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.
Enable sparse protocol in CI
This enables the sparse protocol in CI in order to exercise and dogfood it. This is intended test the production server in a real-world situation.
Fix split-debuginfo support detection
### What does this PR try to resolve?
cargo assumed that if `-Csplit-debuginfo=packed` worked, all values would be correct. This however is not the case -- as of Rust 1.65.0, rustc supports `packed`, but not `unpacked` or `off` on Windows. Because of this, having `split-debuginfo="unpacked`" on Windows has caused builds to fail, as cargo assumed that the option is fine (`split-debuginfo=packed` worked), but rustc then failed when being passed `-Csplit-debuginfo=unpacked`.
### How should we test and review this PR?
Consider an empty project with the following change to `Cargo.toml`:
```toml
[profile.dev]
split-debuginfo="unpacked"
```
`cargo +1.64.0 build` will work, but `cargo +1.65.0 build` will fail with the following error message:
```
PS C:\REDACTED> cargo build
Compiling tmp v0.1.0 (C:\REDACTED)
error: `-Csplit-debuginfo=unpacked` is unstable on this platform
error: could not compile `tmp` due to previous error
```
With this patch and 1.65.0 rustc, cargo will ignore all `split-debuginfo` settings, but with https://github.com/rust-lang/rust/pull/104104 rustc (approved, awaiting merge), it will properly detect supported values for `split-debuginfo` and only ignore those that are unsupported.
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
book: describe how the current resolver sometimes duplicates deps
### What does this PR try to resolve?
This updates the book to document the behavior described in #9029, where sometimes Cargo will duplicate a dep when it doesn't have to.
### How should we test and review this PR?
Doc-only change; someone with knowledge of the resolver should read and assess.
`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.
Link CoC to www.rust-lang.org/conduct.html
Just noticed that Cargo is missing a CoC file while browsing its open source project metrics.
This PR effectively does what `rust-lang/rust` and others projects do.
Add a note about verifying your email address on crates.io
crates.io requires you to verify your email address. This is not picked up by `cargo publish --dry-run`
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)
Fix unused attribute on Windows.
The change introduced in #11610 is causing unused_attribute warnings on Windows because there are two `ignore` attributes when CARGO_PUBLIC_NETWORK_TESTS is not set. The solution here is to make `cargo_test` support a hard-coded option for an additional reason to ignore a test.
Ideally I think this would use something like a `cfg()` expression, but those can't really be evaluated within the proc-macro (without pulling in `cargo_platform`). Could also just `allow(unused_attributes)`, but that felt a little icky.
