fix(test): Move 'cargo_home' from 'install' to 'paths'
### What does this PR try to resolve?
This is used outside of `cargo install` contexts and this makes it more
discoverable for those use cases. That I found places that weren't using `cargo_home` but could helps illustrate the point.
### How should we test and review this PR?
### Additional information
fix(test)!: Clarify extension trait role with rename
When browsing the docs, I feel like this will make it easier to tell the role of these traits within the API.
Or in other words, I can easily tell that these fill a support role and for what, so I know when I care to look into them.
We use this naming pattern for
`cargo_test_support::paths::CargoPathExt`.
When browsing the docs, I feel like this will make it easier to tell the
role of these traits within the API.
Or in other words, I can easily tell that these fill a support role and
for what, so I know when I care to look into them.
We use this naming pattern for
`cargo_test_support::paths::CargoPathExt`.
fix(test): Move path2url to CargoPathExt::to_url
### What does this PR try to resolve?
This is a small step, like #14243, to improve the clarity of `cargo-test-support`s API.
Overall, I'm trying to make it more obvious on https://docs.rs/cargo-test-support/latest/cargo_test_support/ which items to reach for when. I figured this is one that could be demoted to `paths` When doing so, I noticed `CargoPathExt`. I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
### How should we test and review this PR?
### Additional information
I was considering moving this into `paths` and noticed `CargoPathExt`.
I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
Fix passing of links-overrides with target-applies-to-host and an implicit target
### What does this PR try to resolve?
This fixes the link-overrides half of #14195, both the panic, and the fact that the field is being discarded, the latter of which caused the former as discussed in [the issue](https://github.com/rust-lang/cargo/issues/14195#issuecomment-2211481773).
It does so following the blueprint laid out in #13900 - which is also in my opinion the current best summary of the broader context.
### How should we test and review this PR?
For reviewing, comparing to the changes in #13900 might be useful.
### Additional information
I'm pushing a PR for the other half of #14195 simultaneously. I thought it better to keep the PRs small since they're independent, though if merged simultaneously there will be a conflict over the ordering of fields in `Unit`.
Migrate global_cache_tracker snapbox
Part of #14039.
Some of these tests may require to assert specific removed file count or size that would be redact by current design. Need feedback to come out solution.
Temporary commit to pass the tests and illustrate what need to fix.
make summary sync by using Arc not Rc
### What does this PR try to resolve?
For my PubGrub testing work I want to be able to read the entire crates.io index into memory and then run lots of resolution questions against that data in parallel. Currently cargoes `Summary` and `Dependency` types use `Rc` internally which prevents this pattern. Using `Arc` in cargo makes my life a lot easier! It does not noticeably slow down single threaded performance. (Measured by running my PubGrub testing in single threaded mode before and after.)
The team largely agreed to this at a meeting and in discussions https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Make.20summary.20sync
### How should we test and review this PR?
Tests still pass
### Additional information
Should be add a test a this is sync?
chore(ci): bump CI tools
### What does this PR try to resolve?
* Bump cargo-semver-checks to 0.32.0, which supports rustdoc JSON format v30
* Bump mdbook to 0.4.40, and change `curly-quotes` to `smart-punctuation`
### How should we test and review this PR?
Wait for CI green.
### Additional information
test: migrate fetch and list_availables to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:
- `tests/testsuite/fetch.rs`
- `tests/testsuite/list_availables.rs`
chore: downgrade to jobserver@0.1.28
See https://github.com/rust-lang/jobserver-rs/issues/99
While there is a fix waiting for review,
we might miss the release window for 1.80,
so propose we beta-backport this
perf(source): Don't `du` on every git source load
### What does this PR try to resolve?
When profiling Zed (#14238), a major factor in their no-op run times is git patches and git dependencies. The slowest operation for each git source is running `du`. This is extraneous for a couple of reasons
- GC isn't stable, slowing people down for a feature they aren't using
- Size tracking was expected to be lazy, only reading sizes when the GC is configured for size, while this was eager
- Git checkouts are immutable but we check on every load
- This optimized for "while filesystem caches are warm" from a checkout operation when checkout operations are rare compared to all of the other commands run on a working directory.
This removes the `du`, relying on the lazy loading that happens in `update_null_sizes`.
For Zed, this removed about 40ms total from the runtime. While by itself, this is below the threshold of being noticed,
- It adds up if any editor integrations are calling `cargo metadata` a lot
- Over time, small gains like this will add up
### How should we test and review this PR?
### Additional information
cc `@ehuss`
When profiling Zed (#14238), a major factor in their no-op run times
is git patches and git dependencies. The slowest operation for each git
source is running `du`. This is extraneous for a couple of reasons
- GC isn't stable, slowing people down for a feature they aren't using
- Size tracking was expected to be lazy, only reading sizes when the GC
is configured for size, while this was eager
- Git checkouts are immutable but we check on every load
- This optimized for "while filesystem caches are warm" from a checkout
operation when checkout operations are rare compared to all of the other
commands run on a working directory.
This removes the `du`, relying on the lazy loading that happens in
`update_null_sizes`.
feat(test): Add cargo_test to test-support prelude
### What does this PR try to resolve?
With where we are at with #14039, I was revisiting our test writing documentation. I was wanting to put more emphasis on rustdoc and found it would be helpful to talk about the concepts if a prelude was used instead of `extern crate`.
### How should we test and review this PR?
Yes, this included some `use` clean ups in tangentially-related commit but its already painful enough
walking through every test file, I didn't want to do it twice.
### Additional information
Add workflow to publish Cargo automatically
One of the last manual pieces of the Rust release process is publishing Cargo, and as it happens after the release itself it is often forgotten (I am often guilty of that). This PR aims to fully automate that.
Nowadays tagging Cargo happens automatically, as the release process creates and pushes a signed tag for the release. So the only piece remaining is automatically executing the `publish.py` script. This PR adds a workflow triggered by the tag push to run `publish.py` with a [rust-lang-owner](https://crates.io/users/rust-lang-owner) scoped token.
The secret is stored in the [`release` environment](https://github.com/rust-lang/cargo/settings/environments/3357627654/edit), which can only be used during tag pushes.
cc `@Mark-Simulacrum`
We now include the prelude in so many places, this simplifies how we can
present how `cargo-test-support` works.
Yes, this included some `use` clean ups but its already painful enough
walking through every test file, I didn't want to do it twice.
test: migrate implicit_features to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:
- `tests/testsuite/implicit_features.rs`
