### What does this PR try to resolve?
Fixes Issue : #14621
Adds more error context for fetching a commit that doesn't exists.
### How should we test and review this PR?
I've created two tests, one for fast_path and one for libgit2.
r? @weihanglo
### What does this PR try to resolve?
This is a follow up to #14639 in prep for Edition 2024
### How should we test and review this PR?
This is stacked on #14753
### Additional information
This was mostly done by clippy via `clippy::doc_markdown`.
I then reviewed it to fix words that shouldn't have it or where `--fix`
put the backtick in the wrong location.
### What does this PR try to resolve?
`cargo remove` already will suggest other tables if appropriate.
`cargo add` auto-corrects `_` and `-`.
This is an extension of the two by suggesting existing dependencies
within the same table that are "close".
Related to #14814
### How should we test and review this PR?
I chose to make alt tables and alt deps mutually exclusive in the
message because I didn't wantto deal with how to separate things if both
show up.
Most likely, people will only expect one or the other and if its in an
alt table, then most likely they mean that.
### Additional information
### What does this PR try to resolve?
Originally it was only included for packages that have executables or
examples for `cargo install`, however this causes inconsistencies and is
kind of unexpected nowadays, e.g. with cdylib crates.
Including it always only slightly increases the crate size and allows
for all crates to know a set of dependency versions that were working,
which can make regression tracking easier.
Fixes https://github.com/rust-lang/cargo/issues/13447
### How should we test and review this PR?
The existing tests are covering this change in all kinds of various
already, and one test that previously asserted that there is *no*
Cargo.lock for library crates was changed to explicitly check for the
new behaviour.
Originally it was only included for packages that have executables or
examples for `cargo install`, however this causes inconsistencies and
is kind of unexpected nowadays, e.g. with cdylib crates.
Including it always only slightly increases the crate size and allows
for all crates to know a set of dependency versions that were working,
which can make regression tracking easier.
Fixes https://github.com/rust-lang/cargo/issues/13447
`cargo remove` already will suggest other tables if appropriate.
`cargo add` auto-corrects `_` and `-`.
This is an extension of the two by suggesting existing dependencies
within the same table that are "close".
I chose to make alt tables and alt deps mutually exclusive in the
message because I didn't wantto deal with how to separate things if both
show up.
Most likely, people will only expect one or the other and if its in an
alt table, then most likely they mean that.
Related to #14814
This was found when updating git submodule in rust-lang/rust
```
---- test::cargo_test_env stdout ----
running `/Users/weihanglo/dev/rust/build/aarch64-apple-darwin/stage2-tools/aarch64-apple-darwin/release/cargo test --lib -- --nocapture`
thread 'test::cargo_test_env' panicked at tests/testsuite/test.rs:3904:10:
test failed running `/Users/weihanglo/dev/rust/build/aarch64-apple-darwin/stage2-tools/aarch64-apple-darwin/release/cargo test --lib -- --nocapture`
error: expected to find:
/Users/weihanglo/dev/rust/build/aarch64-apple-darwin/stage2-tools/aarch64-apple-darwin/release/cargo
did not find in output:
[COMPILING] foo v0.5.0 ([ROOT]/foo)
[FINISHED] `test` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
[RUNNING] unittests src/lib.rs (target/debug/deps/foo-[HASH])
/Users/weihanglo/dev/rust/build/[HOST_TARGET]/stage2-tools/[HOST_TARGET]/release/cargo
```
On non-Windows platform the redacted string became something like below,
which was valid but didn't make sense:
```
[EXE]/[EXE]U[EXE]s[EXE]e[EXE]r[EXE]s[EXE]/[EXE]w[EXE]h[EXE]l[EXE]o[EXE]/[EXE]d[EXE]e[EXE]v[EXE]/[EXE]r[EXE]u[EXE]s[EXE]t[EXE]/[EXE]b[EXE]u[EXE]i[EXE]l[EXE]d[EXE]/[EXE]a[EXE]a[EXE]r[EXE]c[EXE]h[EXE]6[EXE]4[EXE]-[EXE]a[EXE]p[EXE]p[EXE]l[EXE]e[EXE]-[EXE]d[EXE]a[EXE]r[EXE]w[EXE]i[EXE]n[EXE]/[EXE]s[EXE]t[EXE]a[EXE]g[EXE]e[EXE]2[EXE]-[EXE]t[EXE]o[EXE]o[EXE]l[EXE]s[EXE]/[EXE]a[EXE]a[EXE]r[EXE]c[EXE]h[EXE]6[EXE]4[EXE]-[EXE]a[EXE]p[EXE]p[EXE]l[EXE]e[EXE]-[EXE]d[EXE]a[EXE]r[EXE]w[EXE]i[EXE]n[EXE]/[EXE]r[EXE]e[EXE]l[EXE]e[EXE]a[EXE]s[EXE]e[EXE]/[EXE]c[EXE]a[EXE]r[EXE]g[EXE]o[EXE]
```
Here we simply remove the extension and append `[EXE]` at the end.
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
