### 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
fix#15607.
### What does this PR try to resolve?
Current error message about path/git dependency being inside manifest on
`cargo package` and `cargo publish` lacks some information and it can be
confusing. This PR adds some context on which manifest error originates
from, so that users can understand the exact cause of the error cargo
reports.
Hi Everyone!
This is PR for the manifest parsing of the first milestone of [GSoC
Project : Build Script
Delegation](https://summerofcode.withgoogle.com/programs/2025/projects/nUt4PdAA)
### What does this PR try to resolve?
Currently, just a single build script is allowed for each package. This
PR will allow users to create and use multiple build scripts, and is
backward compatible with single script as well as boolean values.
**Motivation :** This will help users to maintain separate smaller and
cleaner build scripts instead of one large build script. This is also
necessary for build script delegation.
**Open questions:**
- What should the build script target names be?
- Currently they use the file stem of the build script which could run
into conflicts
**Known Issues:**
- This is just parsing support, and currently, only the first build
script of the array is actually executed.
### How to test and review this PR?
There is a feature gate `multiple-build-scripts` that can be passed via
`cargo-features` in `Cargo.toml`. So, you have to add
```toml
cargo-features = ["multiple-build-scripts"]
```
Preferably on the top of the `Cargo.toml` and use nightly toolchain to
use the feature
**This PR is ready to be reviewed and merged**
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.
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`.
### How to test and review this PR?
The tests in the testsuite demonstrate both that the option works as
expected and that it gets ignored with a warning if not passing
`-Zprofile-hint-mostly-unused`.
This will remain a draft until
https://github.com/rust-lang/rust/pull/135656 gets merged in rustc; once
that happens, the "nightly" jobs will pass in CI.
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`.
fix#15656
### What does this PR try to resolve?
This PR implements custom TAB completer for cargo remove <package_name>.
### How to test and review this PR?
This patch works like this:
```console
$ cat Cargo.toml
[package]
name = "sandbox"
version = "0.1.0"
edition = "2024"
[dependencies]
rand = "0.9.1"
serde_json = "1"
$ ~/cargo/target/debug/cargo remove
completing values
--build -- Remove from build-dependencies
--color -- Coloring
--config -- Override a configuration value
--dev -- Remove from dev-dependencies
--dry-run -- Don't actually write the manifest
--frozen -- Equivalent to specifying both --locked and --offline
--help -- Print help
--locked -- Assert that `Cargo.lock` will remain unchanged
--lockfile-path -- Path to Cargo.lock (unstable)
--manifest-path -- Path to Cargo.toml
--offline -- Run without accessing the network
--package -- Package to remove from
--quiet -- Do not print cargo log messages
--target -- Remove from target-dependencies
--verbose -- Use verbose output (-vv very verbose/build.rs output)
-Z -- Unstable (nightly-only) flags to Cargo, see 'cargo -Z help' for details
rand serde_json
```
(on zsh)
