Read a real target spec JSON so we no longer need to hardcode
a target spec JSON here.
Cargo itself should not care about the spec schema.
Let's stop bothering compiler contributors.
The `aarch64-pc-windows-msvc` target is on the path to being promoted to
Tier 1: <https://github.com/rust-lang/rfcs/pull/3817>
Adding Arm64 Windows runners will catch any potential issues in Cargo
before changes are merged in, instead of waiting for the Cargo submodule
to be updated.
### What does this PR try to resolve?
via issue #15505, Cargo currently errors on
```toml
[dependencies]
crc32fast = true
```
with a message about `expected a version string or a detailed
dependency` It doesn’t hint that you can depend on a workspace member.
This PR updates `cargo` so that when you write dep = true, the error
also suggests:
```toml
dep = { workspace = true }
dep.workspace = true
```
### How should we test and review this PR?
In a workspace crate’s Cargo.toml, add
```toml
[dependencies]
crc32fast = true
```
Run `cargo build` and you should see the enhanced error with the two
workspace hints.
### Additional information
Regarding support for int/float, we only need a special case for boolean
because they’re the only values that get the `workspace hint`.
Everything else just uses the normal detailed dependency error
### What does this PR try to resolve?
This PR makes `UnitGenerator` public for experimenting with unit graph
generation in cargo plumbing commands.
See https://github.com/crate-ci/cargo-plumbing/issues/39
### How to test and review this PR?
Verify that `UnitGenerator` is available when using cargo-as-a-library
### 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?
