### What does this PR try to resolve?
This is preparation for changes like #15917 where we start to use
`annotate_snippets::Report` for handling more of the rendering of our
user messages to be more consistent with rustc and more feature rich in
what we are able to render.
### How to test and review this PR?
### What does this PR try to resolve?
This sets up the frontmatter logic as being more standalone in prep for
- Adding a custom error type that tracks spans for a more rustc-like
error experience
- Potentially moving this out into a dedicated package
### How to test and review this PR?
### Notes
Had this sitting around for a while but haven't been able to finish the
work that builds on it so wanted this merged to reduce conflicts.
### What does this PR try to resolve?
When splitting `build-dir` out of `target-dir` (see #14125), we kept
`.crate` files as final artifacts of `cargo package`. However, that also
made them final artifacts of `cargo publish` when the side effect of
that should be the publish operation.
This changes things so that we instead package within `build-dir` and
`cargo package` then uplifts these to `target-dir`.
Behavior change: when running `cargo publish` without `build-dir` set,
`target/package/*.crate` will be moved to
`target/package/tmp-crate/*.crate`. This should be fine as its an
intermediate artifact but there is a risk that this can break someone
who did not realize that. Part of the reason for making the `build-dir`
/ `target-dir` split is to make our intermediate/final artifact intent
clearer. We did intend to be a transition period before changing things,
like with #15010. I'm assuming its fine that we don't have a transition
period here.
### How to test and review this PR?
### Notes
This was discussed at [#t-cargo > `-Zbuild-dir` and `cargo
publish` / `cargo package` @
💬](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/.60-Zbuild-dir.60.20and.20.60cargo.20publish.60.20.2F.20.60cargo.20package.60/near/537336819)
### 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.
