I'm unsure how we should be replacing these use cases, so I'm exploring
keeping them but making them use snapbox under the hood.
Part of the intent of snapbox is that it provides you the building
blocks to make what you need.
test(gc): Update remaining unordered tests to snapbox
### What does this PR try to resolve?
This gets rid of the last unordered tests and removes the functions from `cargo-test-support` as part of #14039
Some tests are being less specific than they were before but in talking to ehuss, it sounded like that was ok.
### How should we test and review this PR?
### Additional information
Normalize the `target` paths
### What does this PR try to resolve?
The `targets` path of the `normalized_toml` could be relative, which isn't user-friendly.
What is this PR doing?
This PR applys the `paths::normalize_path` to remove the relative part.
Fixes#14227
### How should we test and review this PR?
Add a test originted from the issue, and fixing it in the next commit.
### Additional information
rustfix: replace special-case duplicate handling with error
### What does this PR try to resolve?
This PR changes how conflicts are handled in `rustfix`.
By design, `cargo fix` repeatedly compiles the code, collects suggested changes, and applies changes that don't conflict with one another. Often, conflicts arise because the same suggestion is reported multiple times e.g., due to a macro expansion. There have been previous changes to address that specific case, but following [the PR to add transactional semantics](https://github.com/rust-lang/cargo/pull/14747), it makes sense to change how this is handled.
Specifically, this PR adds details to `Error::AlreadyReplaced` to indicate whether the specific replacement is identical to the one it conflicts with, allowing callers to handle this case, rather than special-casing it within `replace.rs` itself. To that point, this PR changes `fix.rs` and `lib.rs` to handle identical replacements by skipping the conflicting suggestion. This is not exactly identical to their previous behavior: before, it skipped a suggestion if any _solution_ had been applied, whereas this skips it if any _replacement within a solution_ has been applied. While more expansive, this is very much the spirit of the goal described above.
### How should we test and review this PR?
The existing tests have been updated to account for this change.
### Additional information
See: https://github.com/rust-lang/cargo/issues/13027
test: Update some emaining unordered tests to snapbox
### What does this PR try to resolve?
This is part of #14039
This leaves `global_cache_tracker.rs` as it requires some more thinking.
As for the flakiness in `freshness.rs` that was seen in #14161, `compare.rs` would prioritize expected lines according to their length (assuming its more specific). Currently, snapbox prioritizes according to the line order. So we just need to put the proc-macro line before the other one to ensure it gets precedence.
### How should we test and review this PR?
### Additional information
Add transactional semantics to `rustfix`
### What does this PR try to resolve?
This PR adds transactional semantics to `rustfix::Data`, enabling `rustfix::CodeFix` to apply `Suggestion`s as atomic units and rollback partially-applied changes when they conflict with existing ones. The basic approach and goals are discussed [in a comment on issue 14699](https://github.com/rust-lang/cargo/issues/14699#issuecomment-2427501232). In that comment, I proposed a solution which extended the existing `State` enumeration, but described an alternative that simplifies the overall tracking of incoming changes; this PR implements the latter.
### How should we test and review this PR?
I've added an additional test and updated the existing ones. The tests in `parse_and_replace` already cover this case, particularly thanks to https://github.com/rust-lang/cargo/pull/14765 added by `@weihanglo.` It's still a good idea to experiment with `cargo clippy --fix` on repos that match the cases described in these open issues.
### Additional information
Fixes#14699
Fixes rust-lang/rust-clippy/issues/13549
doc: fix `GlobalContext` reference
### What does this PR try to resolve?
Commit 67b5aa4205b0248c78d4fba57b3ddaa9cb694327 renamed config with context. This PR adjusts sources to changes.
### How should we test and review this PR?
### Additional information
chore: update handlebars to v6, fix build error
`DirectorySourceOptions` is marked as `#[non_exhaustive]`, and only exposes the Default trait, so we need to instantiate a mutable instance using `default()`, and then change `tpl_extension` to the value we want.
Fixes#14764
DirectorySourceOptions is marked as #[non_exhaustive], and only
exposes the Default trait, so we need to instantiate a mutable
instance using default(), and then change tpl_extension to the
value we want.
Add more metadata to `rustc_fingerprint`
Previously, `rustc_fingerprint` was only using the path and mtime for each executable, but this is not always sufficient. For example, Fedora will [clamp mtimes] to help reproducible builds, so Rust 1.82 looks like `/usr/bin/rustc` and `2024-10-17 00:00:00` across all builds in Fedora 39 through 42 (rawhide), even though they are different in their full version strings, LLVM, etc.
[clamp mtimes]: https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
If the target directory (including `.rustc_info.json`) is shared across such systems, the fingerprint wouldn't notice the difference, and cargo would try to use artifacts that aren't actually compatible, like:
```
error[E0514]: found crate `autocfg` compiled by an incompatible version of rustc
--> build.rs:2:14
|
2 | let ac = autocfg::new();
| ^^^^^^^
|
= note: the following crate versions were found:
crate `autocfg` compiled by rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc42): [...]/target/debug/deps/libautocfg-589c41db1eea6297.rlib
= help: please recompile that crate using this compiler (rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc40)) (consider running `cargo clean` first)
```
We can improve this situation by adding the file length, although that could also happen to be the same, and the creation date that will match when the file was installed, though not all filesystems support that. All of this comes from a single metadata call, so it shouldn't have any noticeable slowdown that would hurt the caching effort.
chore(deps): update rust crate security-framework to v3
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [security-framework](https://lib.rs/crates/security_framework) ([source](https://redirect.github.com/kornelski/rust-security-framework)) | workspace.dependencies | major | `2.11.1` -> `3.0.0` |
---
### Release Notes
<details>
<summary>kornelski/rust-security-framework (security-framework)</summary>
### [`v3.0.0`](https://redirect.github.com/kornelski/rust-security-framework/compare/v2.11.1...v3.0.0)
[Compare Source](https://redirect.github.com/kornelski/rust-security-framework/compare/v2.11.1...v3.0.0)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 5am on the first day of the month" (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:eyJjcmVhdGVkSW5WZXIiOiIzOC4xMzUuMiIsInVwZGF0ZWRJblZlciI6IjM4LjEzNS4yIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbXX0=-->
fix(util): Respect all `..`s in `normalize_path`
### What does this PR try to resolve?
The fact that `normalize_path` was only designed for absolute paths bit us when working out #14497 and so I decided to make sure it worked. The other alternative I considered was having it assert that the path was absolute.
Since I did try out the assert and Cargo tests hit it, this likely fixes something but I haven't dug through to be able to say what.
### How should we test and review this PR?
### Additional information
Previously, `rustc_fingerprint` was only using the path and mtime for
each executable, but this is not always sufficient. For example, Fedora
will [clamp mtimes] to help reproducible builds, so Rust 1.82 looks like
`/usr/bin/rustc` and `2024-10-17 00:00:00` across all builds in Fedora
39 through 42 (rawhide), even though they are different in their full
version strings, LLVM, etc.
[clamp mtimes]: https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
If the target directory (including `.rustc_info.json`) is shared across
such systems, the fingerprint wouldn't notice the difference, and cargo
would try to use artifacts that aren't actually compatible, like:
```
error[E0514]: found crate `autocfg` compiled by an incompatible version of rustc
--> build.rs:2:14
|
2 | let ac = autocfg::new();
| ^^^^^^^
|
= note: the following crate versions were found:
crate `autocfg` compiled by rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc42): [...]/target/debug/deps/libautocfg-589c41db1eea6297.rlib
= help: please recompile that crate using this compiler (rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc40)) (consider running `cargo clean` first)
```
We can improve this situation by adding the file length, although that
could also happen to be the same, and the creation date that will match
when the file was installed, though not all filesystems support that.
All of this comes from a single metadata call, so it shouldn't have any
noticeable slowdown that would hurt the caching effort.
refactor(test): Remove dead 'expect_stdout_contains_n' check
### What does this PR try to resolve?
This was missed when removing the assert
This is part of #14039
### How should we test and review this PR?
### Additional information
add unstable -Zroot-dir flag to configure the path from which rustc should be invoked
This implements the proposal described [here](https://github.com/rust-lang/cargo/issues/9887#issuecomment-2273742881): we add a new flag, for now called `-Zroot-dir`, that configures the directory relative to which rustc is given the crate root filenames to build. (Files outside this directory are passed absolutely.)
This is necessary to be able to fix (no github don't close that issue yet) https://github.com/rust-lang/rust/issues/128726: in multi-workspace repositories that use scripts to manage a whole bunch of cargo invocations, currently the output cargo+rustc produce is often hard or even impossible to interpret for both human and machine consumption. This is because directories in the output are always relative to the workspace root, but when cargo is invoked many times for different workspaces, it is quite unclear what the workspace root is for the invocation that failed.
So I suggest we should have a new flag that the build script in such a repo can set to the consistent "root dir" that the user would recognize as such (e.g., the root of the rustc source tree), and all paths emitted by cargo and rustc should be relative to that directory.
I don't know all the places that cargo itself emits paths (if any), but this PR changes the way we invoke rustc to honor the new flag, so all paths emitted by rustc will be relative to the `-Zroot-dir`.
See https://github.com/rust-lang/rust/pull/132390 for the changes needed in rustc bootstrap to wire this up; together, that suffices to finally properly show errors in RA for all parts of the rustc src tree. :)
docs(resolver): Further v3 prep
### What does this PR try to resolve?
This is a follow up to #14725
### How should we test and review this PR?
### Additional information
fix: track version in fingerprint dep-info files
### What does this PR try to resolve?
Encodes the version information into Cargo's fingerprint dep-info files,
so that when the format encoding changes in the future,
Cargo understands a dep-info file was outdated and doesn't bother parsing it.
Since there was no version info encoded in the old format (call it v0),
to be compatible with older cargoes,
this PR works around it with a horrible hack.
It is explained in the doc comment of `EncodedDepInfo`.
### How should we test and review this PR?
This PR also adds a static file which is v0 depinfo,
to ensure newer cargoes give up parsing it successfully without allocation errors.
See the allocation failures in this CI job result: https://github.com/weihanglo/cargo/actions/runs/11601065840/job/32302943597
It is no harm to keep the v0 test file also fine with removing it from git.
### Additional information
Fixesrust-lang/cargo#14712
test: Remove unused msrv-policy
### What does this PR try to resolve?
Missed this in #14639
### How should we test and review this PR?
### Additional information
Encodes the version information into Cargo's fingerprint dep-info files,
so that when the format encoding changes in the future,
Cargo understands a dep-info file was outdated and doesn't bother parsing it.
Since there was no version info encoded in the old format (call it v0),
to be compatible with older cargoes,
this PR works around it with a horrible hack.
It is explained in the doc comment of `EncodedDepInfo`.
download targeted transitive deps of with artifact deps' target platform
### What does this PR try to resolve?
Fixes#12554. `download_accessible` will now download platform-specified deps of artifact deps with `target = ...`.
It will also resolve the panic in `cargo tree -Z bindeps` in [#10593 (comment)](https://github.com/rust-lang/cargo/issues/10593#issuecomment-1317759526), where:
- a dependency of an artifact dependency is platform specified
- artifact dep itself is { target = } with the same platform as its own dependency
- the platform is not activated.
Essentially, `no entry found for key` was happening because for artifact deps with `{.., target = <target>}`, transitive deps that specified their platform as `<target>` were not downloaded. This is why adding `--target all` to `cargo tree -Z bindeps` made the bug dissapear.
### How should we test and review this PR?
Tests included in this PR should be enough.
~~Test `artifact_dep::proc_macro_in_artifact_dep` still throws; this PR will be ready for review once the test does not panic.~~
### Additional Information
`used` set needs to be target-aware
r? `@weihanglo`
