Overwrite `$CARGO` when the current exe is detected to be a cargo
binary.
From
https://github.com/rust-lang/cargo/issues/15099#issuecomment-2666737150:
> opt-in behavior (set by cargo-the-bin):
>
> 1. `from_current_exe` if its `cargo[EXE_SUFFIX]`
> 2. `from_argv` if its `cargo[EXE_SUFFIX]`
> 3. `from_env`
> 4. `from_current_exe`
> 5. `from_argv`
r? @epage
### What does this PR try to resolve?
The old behavior gets members from `default-members` if specified in a
virtual workspace, this PR gets all workspace members for `Available`
target hints.
Fixes https://github.com/rust-lang/cargo/issues/14544
### How should we test and review this PR?
The first commit added the test, the second commit addressed the issue.
### Additional information
### What does this PR try to resolve?
Just found we can simplify `human_readable_bytes` a bit.
This also remove the `bytesize` dependency,
since we already have a hand-rolled function.
(It is a good crate, though)
### How should we test and review this PR?
Should have no real functional difference.
`cargo package` starts reporting IEC (KiB) instead of SI (KB).
So do some thresholds of `cargo package`.
Could also switch entirely to `bytesize` if that is preferred.
### Additional information
### What does this PR try to resolve?
This likely only affects `-Zpackage-workspace` but it might have also
broken dependencies whose path ends with `.rs` as
well
This broke in https://github.com/rust-lang/cargo/pull/14961
### How should we test and review this PR?
### Additional information
I found when debugging some issues with edges,
having to track indices was making things much more difficult.
My hope is this will help with little negative impact.
We could put this behind a `#[cfg(debug_asserts)]` but I'm assuming it
doesn't make enough of a performance difference to matter.
When `--exclude-lockfile` is enabled,
`cargo package` will not verify the lock file if present,
nor will it generate a new one if absent.
Cargo.lock will not be included in the resulting tarball.
Together with `--no-verify`,
this flag decouples packaging from checking the registry index.
While this is useful for some non-normal workflows that requires
to assemble packages having unpublished dependencies.
It is recommended to use `-Zpackage-workspace` to package the entire
workspace, instead of opting out lockfile.
### What does this PR try to resolve?
This was reported at
https://github.com/rust-lang/cargo/issues/10948#issuecomment-2674289330
For the exact mapping between the publish payload and the index,
see
https://doc.rust-lang.org/cargo/reference/registry-index.html#json-schema,
particularly the note about differences.
### How should we test and review this PR?
### Additional information
I suspect there is a second bug here because my debugging only showed us
hitting this scenario for `val-json` and not `concepts` and only when
building `utils`. That difference in behavior between a transitive and
direct dependency is odd.
## What does this PR try to resolve?
This PR adds a new `build.build-dir` configuration option that was
proposed in
https://github.com/rust-lang/cargo/issues/14125#issuecomment-2258708917
This new config option allows the user to specify a directory where
intermediate build artifacts should be stored.
I have shortened it to just `build-dir` from `target-build-dir`,
although naming is still subject to change.
### What is a final artifact vs an intermediate build artifact
#### Final artifacts
These are the files that end users will typically want to access
directly or indirectly via a third party tool.
* binary executable for bin crates
* binary executable for examples
* `.crate` files output from `cargo package`
* [depinfo
files](https://doc.rust-lang.org/cargo/reference/build-cache.html#dep-info-files)
(`.d` files) for third party build-system integrations (see
https://github.com/rust-lang/cargo/blob/master/src/cargo/core/compiler/fingerprint/mod.rs#L194)
* `cargo doc` output (html/css/js/etc)
* Cargo's
[`--timings`](https://doc.rust-lang.org/cargo/reference/timings.html)
HTML report
#### Intermediate build artifact, caches, and state
These are files that are used internally by Cargo/Rustc during the build
process
* other depinfo files (generated by rustc, fingerprint, etc. See
https://github.com/rust-lang/cargo/blob/master/src/cargo/core/compiler/fingerprint/mod.rs#L164)
* rlibs and debug info from dependencies
* build script `OUT_DIR`
* output from proc macros (previously stored in `target/build`)
* [incremental
build](https://doc.rust-lang.org/rustc/codegen-options/index.html#incremental)
output from rustc
* fingerprint files used by Cargo for rebuild detection
* scratchpad used for `cargo package` verify step
* Cache of rustc invocations (`.rustc_info.json`)
* "pre and non uplifted" binary executables. (ie. bins for `examples`
that contain the hash in the name, bins for `benches`, proc macros,
build scripts)
* `CARGO_TARGET_TMPDIR` files (see rational for this
[here](https://github.com/rust-lang/cargo/issues/14125#issuecomment-2258708917))
*
[future-incompat-report](https://doc.rust-lang.org/cargo/reference/future-incompat-report.html)'s
`.future-incompat-report.json` file
## Feature Gating Strategy
We are following the "Ignore the feature that is used without a gate"
approach as described
[here](https://doc.rust-lang.org/nightly/nightly-rustc/cargo/core/features/index.html).
The rational for this is:
The `build.build-dir` is likely going to be set by by users "globally"
(ie. `$CARGO_HOME/config.toml`) to set a shared build directory to
reduce rebuilding dependencies. For users that multiple cargo versions
having having an error would be disrupted.
The fallback behavior is to revert to the behavior of the current stable
release (building in `$CARGO_TARGET_DIR`)
## Testing Strategy
* We have the existing Cargo testsuite to be sure we do not introduce
regressions.
* I have also run the testsuite locally with the cli flag remove to
verify all tests pass with the default build dir (which falls back to
the target dir)
* For testing thus far, I have been using small hello world project with
a few dependencies like `rand` to verify files are being output to the
correct directory.
* When this PR is closer to merging, I plan to test with some larger
projects with more dependencies, build scripts, ect.
* Other testing recommendations are welcome 🙇
## How should we test and review this PR?
This is probably best reviewed commit by commit. I documented each
commit.
I tied to follow the atomic commits recommendation in the Cargo
contributors guide, but I split out some commits for ease of review.
(Otherwise I think this would have ended up being 1 or 2 large commits
😅)
## Questions
- [x] What is the expected behavior of `cargo clean`?
* At the time of writing it only cleans `target` and does not impact the
build-dir but this is easily changable.
* Answer: See
https://github.com/rust-lang/cargo/pull/15104#issuecomment-2616369862
- [x] When using `cargo package` are was expecting just the `.crate`
file to be in `target` while all other output be stored in
`build.build-dir`? Not sure if we consider things like `Cargo.toml`, `
Cargo.toml.orig`, `.cargo_vcs_info.json` part of the user facing
interface.
* Current consensus is that only `.crate` is considered a final artifact
- [x] Where should `cargo doc` output go? HTML/JS for many crates can be
pretty large. Moving to the build-dir would help reduce duplication if
we find the that acceptable. For `cargo doc --open` this is not a
problem but may be problematic for other use cases?
* Answer:
https://github.com/rust-lang/cargo/pull/15104#issuecomment-2619760470
- [x] Are bins generated from `benches` considered final artifacts?
* Since bins from `examples` are considered final artifacts, it seems
natural that `benches` should also be considered final artifacts.
However, unlike `examples` the `benches` bins are stored in
`target/{profile}/deps` instead of a dedicated directory (like
`target/{profile}/examples`). We could move them into a dedicated
directory (`target/{profile}/benches`) but that mean would also be
changing the structure of the `target` directory which feels out of
scope for this change. If we decide that `benches` are final artifacts,
it would probably be better to consider that changes as part of
https://github.com/rust-lang/cargo/issues/6790
* Answer:
https://github.com/rust-lang/cargo/pull/15104#issuecomment-2636519011
- [ ] [Do we want to include a `CARGO_BUILD_DIR` shortcut env
var?](https://github.com/rust-lang/cargo/pull/15104#discussion_r1943404348)
* The current commit (2af0c918d415b4de03e627459c3594826ae03cfb) has
included the `CARGO_BUILD_DIR` shortcut. This can be removed before
merging if there a good reason to.
## TODO
- Implementation
- [x] Add support in `cargo clean`
- [ ] ~~Implement templating for `build.build-dir`~~
* Will implement in a follow up PR [as
suggested](https://github.com/rust-lang/cargo/pull/15104#issuecomment-2636514628)
- [x] Fix issue with `target/examples` still containing "pre-uplifted"
binaries
- [x] Verify `build-dir` with non-bin crate types
- Prepare for review
- [x] Clean up/improve docs
- [x] Review tests and add more as needed
- [x] Fix tests in CI (Windows is currently failing)
- [x] Clean up commits
- [ ] Resolve remaining questions
- [x] Request review
### What does this PR try to resolve?
We have the `resolver` field in their as subtle nod to encourage people
to explicitly set it in workspaces. With `resolver = "3"` being out for
a couple releases (at the time this hits stable), it seems appropriate
for us to bump this value.
### How should we test and review this PR?
### Additional information
We have the `resolver` field in their as subtle nod to encourage people
to explicitly set it in workspaces. With `resolver = "3"` being out for
a couple releases (at the time this hits stable), it seems appropriate
for us to bump this value.
