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
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 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. :)
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
Remove requirement for --target when invoking Cargo with -Zbuild-std
This PR addresses [this issue](https://github.com/rust-lang/wg-cargo-std-aware/issues/25) re: build-std stabilization. We believe the requirement for --target to be specified when invoking cargo with -Zbuild-std, from our testing, is no longer needed. Now, with this change, by default Cargo will use the Host CompileKind, rather than a manually specified CompileTarget. We propose removing this restriction in order to test this more widely. Our own testing is detailed below.
This change has been tested in the following manner:
* Building crates depending on proc_macro, std, and build scripts (which themselves depend on proc_macro)
* Various RUSTFLAGS, such as `-Zsanitizer=cfi`, `-Cembed-bitcode=yes`, `-Cforce-frame-pointers`, `-Cforce-unwind-tables=yes`, `-Csoft-float=yes`, `-Zbranch-protection=pac-ret`.
Allow build scripts to report error messages through `cargo::error`
Adds the `cargo::error` build script directive. It is similar to `cargo::warning`, but it emits an error message and it also fails the build.
This is a repost of #14435 with the tests updated, a note added to the documentation about using this in a library, and updating the MSRV.
Closes#10159
fix(publish): Downgrade version-exists error to warning on dry-run
### What does this PR try to resolve?
Especially for beta, this was the most conservative, minimal change.
Fixes#14721
### How should we test and review this PR?
### Additional information
This will get cherry-picked to beta
test(install): Verify 2024 edition / resolver=3 doesn't affect resolution
### What does this PR try to resolve?
I was worried there might be bugs related to this. With this out of the way, I think we'll be ready to stabilize `resolver = "3"`.
### How should we test and review this PR?
### Additional information
Fix: trace `config` `[env]` table in dep-info.
### What does this PR try to resolve?
The `env` defined in `config.toml` or `--config env` are stripped before recording in the dep-info file. The absence of the env table doesn't rebuild when env changed
By tracing the `env` table into the `dep-info` file, If the envs changed then the rebuild can be triggered.
Fixes#13280
### How should we test and review this PR?
One commit add the test, the latter commit update the test through the fixes.
### Additional information
The PR only fixed the `env` table changes can't trigger a rebuild, other `CARGO-like` envs
doesn't take into account.
`Registry::describe_source` will be used as default error message, but if the message
come from `Registry::describe_source` is empty, then it uses `SourceId` message
