### What does this PR try to resolve?
This PR resolves: https://github.com/rust-lang/cargo/issues/13051
Namely, it allows users to invoke cargo subcommands that accept a
`--target` directive to specify the `host` target, which is later
substituted in the command processing layer by the host's real target
triple (for instance, on most Linux distributions, `cargo build --target
host` would effectively run `cargo build --target
x86_64-unknown-linux-gnu`).
This additionally applies to usage within `config.toml`, like so:
```toml
# .cargo/config.toml
[build]
target = "host"
```
### What does this PR try to resolve?
There is incompatibility between rustix@1.0.8 and libc@0.2.175 that
leads to compilation errors.
See
* https://github.com/bytecodealliance/rustix/issues/1496
* https://github.com/rust-lang/rust/pull/145478#issuecomment-3193494156
### How to test and review this PR?
In rust-lang/rust, update the `src/tools/cargo` submodule accordingly,
and run
```
cargo run --manifest-path src/ci/citool/Cargo.toml run-local dist-loongarch64-musl
```
With this downgrade it should compile.
Aside from `false`, the `lto` options seem to be ordered from "most
optimizing" to "least optimizing".
If this interpretation is correct, then I think `false` should go
between `thin` and `off`.
cc: @ehuss (who I think wrote that text)
### What does this PR try to resolve?
Part of #15844
Set up `-Zbuild-analysis` flag and `build.analysis` configuration table
to lay the ground work.
when `build.analysis.enabled = true`, enables HTML timing output to
pretend we are persisting timing data for now. This will change when the
storage part is implemented.
### How to test and review this PR?
### What does this PR try to resolve?
clarifies that cargo doc --no-deps will not delete previously-built
dependency docs, and points users to cargo clean --doc or manual
deletion if they want a truly “fresh” doc set. This pr fixed
https://github.com/rust-lang/cargo/issues/15728
### How to test and review this PR?
No testing required.
### What does this PR try to resolve?
While working on a [plumbing
command](https://github.com/crate-ci/cargo-plumbing) for feature
resolution, I hit a dead end where the fields and types are private.
This PR changes the needed things into `pub`.
r? @epage
### How to test and review this PR?
`cargo check`
Bumps [slab](https://github.com/tokio-rs/slab) from 0.4.10 to 0.4.11.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tokio-rs/slab/releases">slab's
releases</a>.</em></p>
<blockquote>
<h2>v0.4.11</h2>
<ul>
<li>Fix <code>Slab::get_disjoint_mut</code> out of bounds (<a
href="https://redirect.github.com/tokio-rs/slab/issues/152">#152</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/tokio-rs/slab/blob/master/CHANGELOG.md">slab's
changelog</a>.</em></p>
<blockquote>
<h1>0.4.11 (August 8, 2025)</h1>
<ul>
<li>Fix <code>Slab::get_disjoint_mut</code> out of bounds (<a
href="https://redirect.github.com/tokio-rs/slab/issues/152">#152</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="2e5779f8eb"><code>2e5779f</code></a>
Release v0.4.11 (<a
href="https://redirect.github.com/tokio-rs/slab/issues/153">#153</a>)</li>
<li><a
href="2d65c514bc"><code>2d65c51</code></a>
Fix get_disjoint_mut error condition (<a
href="https://redirect.github.com/tokio-rs/slab/issues/152">#152</a>)</li>
<li>See full diff in <a
href="https://github.com/tokio-rs/slab/compare/v0.4.10...v0.4.11">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/rust-lang/cargo/network/alerts).
</details>
### What does this PR try to resolve?
RFC 3841 has merged, and x86_64-apple-darwin will be demoted to tier-2
in 1.90.0. In Cargo we usually run test against tier-1 platforms, so
x86_64-apple-darwin should be removed.
Also, that target platform is often the slowest one in CI, we are happy
to remove it to save us a couple of minutes.
https://rust-lang.github.io/rfcs/3841-demote-x86_64-apple-darwin.html
### How to test and review this PR?
Run `cargo test` locally with cross-compile tests enabled, and no
regression.
RFC 3841 has merged, and x86_64-apple-darwin will be demoted to tier-2
in 1.90.0. In Cargo we usually run test against tier-1 platforms, so
x86_64-apple-darwin should be removed.
Also, that target platform is often the slowest one in CI,
we are happy to remove it to save us a couple of minutes.
https://rust-lang.github.io/rfcs/3841-demote-x86_64-apple-darwin.html
### What does this PR try to resolve?
While preparing to stabilize `build-dir`, [it was
discovered](https://github.com/rust-lang/cargo/issues/14125#issuecomment-3127467689)
that `cargo package` will sometimes use the build cache for dependency
crates if `CARGO_TARGET_DIR` is explicitly set.
If target-dir is not set, the build will be preformed in an "inner
target dir" at `target/package/{name}-{version}/target` and rebuild
everything.
This PR changes the default behavior to always use the build cache,
matching the behavior of having `target-dir` set.
### How to test and review this PR?
Added a dedicated test to verify the previous behavior (cargo recompiled
non-workspace crates) in the first commit.
Then updated it to verify the new behavior.
### Related links/notes
* I did some Git archaeology and I _think_ this behavior was introduced
in #2912
* While searching through the commit/pr history was never able to find
any explicit reason why the behavior is the way it is.
* Even if it was intentional, it has been 9 years since and Cargo's
fingerprinting/rebuild detection is much more mature now so I believe
its worth revisiting if this is still the desired behavior.
* Would help mitigate https://github.com/rust-lang/cargo/issues/14941
The error message for unknown values of `cargo-features` was unhelpful:
```text
Caused by:
unknown cargo feature `build-dir`
```
I've made it more explanatory, and matching the style of the other
errors:
```text
Caused by:
feature `build-dir` is not a valid unstable feature for Cargo.toml
This feature can be enabled via -Zbuild-dir or the `[unstable]` section in config.toml.
See https://doc.rust-lang.org/cargo/reference/unstable.html for more information.
```
### What does this PR try to resolve?
This PR adds initial support into Cargo for JSON timing sections,
implemented in rustc in https://github.com/rust-lang/rust/pull/142123.
This allows Cargo to read frontend/codegen/linking time from rustc, and
thus reporting slightly more detailed data in the `cargo build
--timings` output.
The PR modifies Cargo to tell rustc to emit the section messages
(`--json=...,timings`), and it adds the section timings data to the HTML
table output and the JSON output. It does not yet integration different
sections in the HTML unit chart (I want to do that as a follow-up).
Note that the JSON timings are currently only supported on the nightly
compiler (they are not stabilized). The new behavior is thus gated
behing an unstable Cargo flag (`-Zsection-timings`). When the flag is
unused, the HTML table should look more or less the same as before, just
that the code now supports both options.
### How to test and review this PR?
You can run e.g. this to generate the timing report with a nightly
compiler:
```bash
export RUSTC=`rustup +nightly which rustc`
target/debug/cargo build -Zsection-timings --timings
```
on some crate, e.g. [ripgrep](https://github.com/BurntSushi/ripgrep).
Tracking issue: https://github.com/rust-lang/cargo/issues/15817
