Fixes#15647.
When dry-run publishing workspace without bumping versions first, the
package-verification step would fail because it would see checksum
mismatches between the old lock file (that saw index deps) and the new
lock file where those index deps got replaced by local packages with the
same version.
In this PR, the packaging step modifies the old lock file's checksums
before re-resolving, but only in dry-run mode.
### What does this PR try to resolve?
This PR reworks `cargo-test-support` and `testsuite` to use Snapbox's
[`cargo_bin!()`](https://docs.rs/snapbox/latest/snapbox/cmd/macro.cargo_bin.html)
instead of
[`cargo_bin()`](https://docs.rs/snapbox/latest/snapbox/cmd/fn.cargo_bin.html)
which makes assumptions about the structure of Cargo's build directory.
`cargo_bin!()` uses `CARGO_BIN_EXE_*` for locating the `cargo` binary
which should be more resilient to directory/layout changes.
Linking a relevant Zulip discussion
[here](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/cargo_bin_exe.20and.20tests/with/513638220)[#t-cargo
> cargo_bin_exe and
tests](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/cargo_bin_exe.20and.20tests/with/513638220)
As shown in that link, we could make these variables available at
runtime and not need to do this. However, `cargo-test-support`, as an
API, is a bit weird in that it is baking in support for one specific
binary. This can be confusing for callers and makes it more annoying for
callers provide their own `fn cargo`, e.g. see crate-ci/cargo-fixit#7
### Implementation Notes
`cargo_bin!()` only works when being called from the `testsuite` as it's
only set when executing integration tests and `cargo-test-support` is a
regular crate.
To make this change, I introduced an extension trait `CargoProjectExt`
in `testsuite` for running `.cargo()` and implemented it on `Project`.
In `cargo-test-support` other functionality relies on `.cargo()` so
these also needed to be moved to `testsuite`
*
[`src/tools.rs`](https://github.com/rust-lang/cargo/blob/master/crates/cargo-test-support/src/tools.rs)
* Parts
[`src/cross_compile`](https://github.com/rust-lang/cargo/blob/master/crates/cargo-test-support/src/cross_compile.rs)
* I had to split this up unfortunately, as `disabled()` requires running
Cargo to check if we should disable cross compile tests.
* Other fns in `cross_compile` are used in `cargo-test-support` so
moving everything to `testsuite` would have ended up requiring moving
many things to test suite.
### How to test and review this PR?
I'd definitely recommend reviewing commit by commit.
There are a lot of diffs due to the nature of reorganizing things.
I did my best to split things things into smaller PRs but they still
contain a lot of `use` statement diffs.
r? @epage
Two tests were using `.rust_version("1.90.0")` for a "newer" Rust, but
this failed in rust-lang/rust#142792 for the start of the *real* 1.90.0.
Let's bump that to 1.999.0 so we won't have to deal with it for a while.
The rustc `-Zhint-mostly-unused` flag tells rustc that most of a crate
will go unused. This is useful for speeding up compilation of large
dependencies from which you only use a few items. Plumb that option
through as a profile option, to allow specifying it for specific
dependencies:
```toml
[profile.dev.package.huge-mostly-unused-dependency]
hint-mostly-unused = true
```
To enable this feature, pass `-Zprofile-hint-mostly-unused`. However,
since this option is a hint, using it without passing
`-Zprofile-hint-mostly-unused` will only warn and ignore the profile
option. Versions of Cargo prior to the introduction of this feature will
give an "unused manifest key" warning, but will otherwise function
without erroring. This allows using the hint in a crate's `Cargo.toml`
without mandating the use of a newer Cargo to build it.
Add a test verifying that the profile option gets ignored with a warning
without passing `-Zprofile-hint-mostly-unused`, and another test
verifying that it gets handled when passing
`-Zprofile-hint-mostly-unused`.
### What does this PR try to resolve?
As of #15625, the manifest path argument in `cargo clippy
--manifest-path foo/Cargo.toml --fix` will be ignored. All the workspace
members will be built. The cause is due to the `reload` usage in
`cargo::ops::fix`. We reload the `root_manifest` in the function, which
contains all workspace members.
Will close#15625.
### How to test and review this PR?
The first commit in the PR demonstrates the current problem, and the
second commit corrects it. Use `cargo test --test testsuite
workspaces::fix_only_check_manifest_path_member` to see the test
results.
### What does this PR try to resolve?
The `clippy::perf` lint group is fairly useful for catching bad
practices that might hurt performance marginally.
This PR fixes most of them except `clippy::large_enum_variant`, which
doesn't feel right at this moment and need more researches. And that is
why I didn't enable the lint group.
### How to test and review this PR?
The `clippy::perf` lint group is fairly useful for catching bad
practices that might hurt performance marginally.
This PR fixes most of them except `clippy::large_enum_variant`,
which doesn't feel right at this moment and need more researches.
Anyway, overall this PR should be good.
### What does this PR try to resolve?
Found this as I was preparing for stabilization.
As we create a graph of packages to ensure publish order, a self-cycle
shouldn't matter, so we can skip tracking it.
### How to test and review this PR?
Remap all paths pointing to `build.build-dir`,
i.e., `[BUILD_DIR]/debug/deps/foo-[HASH].dwo` would be remapped to
`/cargo/build-dir/debug/deps/foo-[HASH].dwo`
(note the `/cargo/build-dir` prefix).
This covers scenarios like:
* Build script generated code. For example, a build script may call `file!`
macros, and the associated crate uses [`include!`] to include the expanded
[`file!`] macro in-place via the `OUT_DIR` environment.
* On Linux, `DW_AT_GNU_dwo_name` that contains paths to split debuginfo
files (dwp and dwo).
