In most cases, this will just be what you passed on the command line.
Even when its not, that likely represents a programmer error.
I mostly did this to help see what was the cause of a test failure.
### What does this PR try to resolve?
When working with the frontmatter parser, I identified some corner cases
that we should cover.
I cannot think of a programmatic way to require escaping when going from
no frontmatter to a frontmatter or to require more escaping than is
already present.
### How to test and review this PR?
I cannot think of a programmatic way to require escaping when going from no frontmatter to a frontmatter
or to require more escaping than is already present.
## What does this PR try to resolve?
This PR fixes issue #15754 where workspace publish failures provided
non-actionable error messages. Previously, when publishing a workspace
failed (due to rate limiting or other errors), users only saw generic
errors like `[ERROR] failed to publish to registry` without knowing
which package failed or what packages remained to be published.
## How to test and review this PR?
**Testing**: Run `cargo test workspace_publish_rate_limit_error` to see
the improved behavior, then `cargo test publish` to ensure all tests
pass.
**Review**:
- **Commit 1**: Adds test demonstrating current problematic behavior
- **Commit 2**: Implements fix and updates test to expect improved
output
The fix transforms error messages from generic `failed to publish to
registry` to actionable `failed to publish 'package_a' v0.1.0; the
following crates have not been published yet: package_b v0.1.0,
package_c v0.1.0`. This improvement applies consistently across all
publish error scenarios, giving users clear information about what went
wrong and what remains to be done.
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)
