### What does this PR try to resolve?
As this is an unordered test, sometimes snapshot updating can mess up
the line order.
### How to test and review this PR?
Several parts of this are not ideal yet
- Frontmatter close should show the open and show the EOF, instead of
pointing at the open
- Trailing content on close will usually have a newline
- Multiple frontmatters should show the original frontmatter
- Some content, like supported infostrings, should go in a help
- Ideally we try to recover on no closing and instead point out a
mismatched open/close
But this is still an improvement over nothing!
### What does this PR try to resolve?
Currently, if you have a manifest parse error for a cargo script, the
line number will be relative to the start of the frontmatter and not the
source file. This changes it so we get the line number relative to the
start of the source file.
### How to test and review this PR?
### Notes
To do this, I added span tracking to our frontmatter parser. To make
this easier, I used some helpers from winnow which is an existing
transitive dependency.
This span tracking will also come into use when I change the frontmatter
parser to start reporting spans in errors so we get annotated snippets
of source in the error messages to users.
### What does this PR try to resolve?
Replace flock with std flock.
### How to test and review this PR?
Given we've supported Oracle since 2022-12 and don't want to break
people,
this is blocked on std supporting flock emulation via fcntl
rust-lang/rust#146269
### What does this PR try to resolve?
Fixes#12740
This is also prep for #15917, #15922
Changes:
- `note` changes from Cyan to Bright Green
- `cargo info` had to be changed because the header and context colors
became the same
- Switch to Bright colors which is usually redundant with Bold but that
is theme dependent
- `warning` only changes to Bright on Windows which is to work around a
shell issue on some Windows versions
- except for `PLACEHOLDER` to tell it apart from `LITERAL`
- the `:` in `note:` is no longer bolded to match rustc
### How to test and review this PR?
### Notes
While annotate-snippets does not have a style for every one of our
styles, I updated our manual styles to be similar to annotate snippets.
For annotate snippets color definitions, see
d38b08b81d/src/renderer/mod.rs (L41-L78)
Given we've supported Oracle since 2022-12
and don't want to break people,
this is blocked on std supporting flock emulation via fcntl
rust-lang/rust 146269
### What does this PR try to resolve?
This PR expands the support for `--json-timings` (added in
https://github.com/rust-lang/cargo/pull/15780), by rendering the
individual compilation sections in the pipeline graph of the `--timings`
page.
Before, the linking section was only shown in the table at the bottom of
the page, now it should also be clearly visible in the compilation
graph, which should help more quickly understand how much time is spent
in linking.
<img width="1219" height="358" alt="image"
src="https://github.com/user-attachments/assets/71d0200d-4175-43b7-8aab-997008e2af47"
/>
I also added a legend to the pipeline graph, to explain what do the
colors mean.
<img width="338" height="118" alt="image"
src="https://github.com/user-attachments/assets/69f9bac6-c33f-44c5-8e45-afa97f314e4c"
/>
One wart is that the linking time actually ends a bit before the unit
ends, so there is some "vacuum" at the end where rustc does cleanup,
persists files to disk, deallocates things, etc. That's why I marked the
blue section "Frontend/rest" in the legend.
### How to test and review this PR?
Same as for https://github.com/rust-lang/cargo/pull/15780, e.g.:
```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).
### What does this PR try to resolve?
Had to deal with manually updating these when changing notes.
This will avoid that.
### How to test and review this PR?
### 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)
