### What does this PR try to resolve?
For frontmatter parser, we almost exclusively use unit tests.
This switches the rustc ui tests we've copied over to being cargo ui
tests but in a way that makes it relatively easy to diff against rustc
and see the state of the two and makes it easier to update.
This will help as I work to improve the errors reported by cargo to
align with rustc in quality
As part of this, I made the source file auto-updating whenever new tests
get copied over.
### How to test and review this PR?
### Notes
Note: the tests are a little ahead of rustc atm, being pulled from one
of my branches that I've not yet pushed because its blocked on another
PR
### What does this PR try to resolve?
Fixed some typos and small grammar things I found while poking around
the registry implementation.
### How to test and review this PR?
Shouldn't need any special testing.
While emitting warnings, if `cargo` encounters a critical warning or an
error while linting, it returns early, potentially before all packages
could emit their warnings or be linted. This could make it so users have
to run a `cargo` command more than once before seeing all of the
relevant output. Beyond this, having an error caused by a lint be a
"stop the world" event seems wrong, as it (currently) doesn't inhibit
outputting other warnings or linting other packages.
To address this, I made it so that `cargo` waits until the end of
`emit_warnings` to return an error if one was encountered. To keep the
cause of the error the same as before, `cargo` saves off the first error
it encounters, and returns it at the end.
### What does this PR try to resolve?
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.
### How to test and review this PR?
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [tracing-subscriber](https://tokio.rs)
([source](https://redirect.github.com/tokio-rs/tracing)) |
workspace.dependencies | patch | `0.3.19` -> `0.3.20` |
### GitHub Vulnerability Alerts
####
[GHSA-xwfj-jgwm-7wp5](https://redirect.github.com/tokio-rs/tracing/security/advisories/GHSA-xwfj-jgwm-7wp5)
### Impact
Previous versions of tracing-subscriber were vulnerable to ANSI escape
sequence injection attacks. Untrusted user input containing ANSI escape
sequences could be injected into terminal output when logged,
potentially allowing attackers to:
- Manipulate terminal title bars
- Clear screens or modify terminal display
- Potentially mislead users through terminal manipulation
In isolation, impact is minimal, however security issues have been found
in terminal emulators that enabled an attacker to use ANSI escape
sequences via logs to exploit vulnerabilities in the terminal emulator.
### Patches
`tracing-subscriber` version 0.3.20 fixes this vulnerability by escaping
ANSI control characters in when writing events to destinations that may
be printed to the terminal.
### Workarounds
Avoid printing logs to terminal emulators without escaping ANSI control
sequences.
### References
https://www.packetlabs.net/posts/weaponizing-ansi-escape-sequences/
### Acknowledgments
We would like to thank [zefr0x](http://github.com/zefr0x) who
responsibly reported the issue at `security@tokio.rs`.
If you believe you have found a security vulnerability in any tokio-rs
project, please email us at `security@tokio.rs`.
---
### Release Notes
<details>
<summary>tokio-rs/tracing (tracing-subscriber)</summary>
###
[`v0.3.20`](https://redirect.github.com/tokio-rs/tracing/releases/tag/tracing-subscriber-0.3.20):
tracing-subscriber 0.3.20
[Compare
Source](https://redirect.github.com/tokio-rs/tracing/compare/tracing-subscriber-0.3.19...tracing-subscriber-0.3.20)
**Security Fix**: ANSI Escape Sequence Injection (CVE-TBD)
#### Impact
Previous versions of tracing-subscriber were vulnerable to ANSI escape
sequence injection attacks. Untrusted user input containing ANSI escape
sequences could be injected into terminal output when logged,
potentially allowing attackers to:
- Manipulate terminal title bars
- Clear screens or modify terminal display
- Potentially mislead users through terminal manipulation
In isolation, impact is minimal, however security issues have been found
in terminal emulators that enabled an attacker to use ANSI escape
sequences via logs to exploit vulnerabilities in the terminal emulator.
#### Solution
Version 0.3.20 fixes this vulnerability by escaping ANSI control
characters in when writing events to destinations that may be printed to
the terminal.
#### Affected Versions
All versions of tracing-subscriber prior to 0.3.20 are affected by this
vulnerability.
#### Recommendations
Immediate Action Required: We recommend upgrading to tracing-subscriber
0.3.20 immediately, especially if your application:
- Logs user-provided input (form data, HTTP headers, query parameters,
etc.)
- Runs in environments where terminal output is displayed to users
#### Migration
This is a patch release with no breaking API changes. Simply update your
Cargo.toml:
```toml
[dependencies]
tracing-subscriber = "0.3.20"
```
#### Acknowledgments
We would like to thank [zefr0x](http://github.com/zefr0x) who
responsibly reported the issue at `security@tokio.rs`.
If you believe you have found a security vulnerability in any tokio-rs
project, please email us at `security@tokio.rs`.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "" (UTC), Automerge - At any time (no
schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS44Mi43IiwidXBkYXRlZEluVmVyIjoiNDEuODIuNyIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
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
