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`
test: migrate build-std/main to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:
- `tests/build-std/main.rs`
test: migrate check_cfg 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/check_cfg.rs`
---
This commit allow deprecation for most of the tests currently in this file. This is because the tests either use `does_not_contain` or perform multiple `contains` assertion for single tool with macro `x!`.
Here are some potential options to further eliminate the deprecation:
1. Remove the `x!` macro and replace the it with `str![]` for both Windows and non-Windows platforms.
2. Modify the `x!` macro to only generate the `--check-cfg` part for different platforms and manually compose it with `format!`.
refactor(source): More RecursivePathSource clean up
### What does this PR try to resolve?
This is a follow up to #13993 and #14169 and is part of my work towards #10752.
### How should we test and review this PR?
### Additional information
Primary benefit: looking to track more state in `RecursivePathSource`
and this is a stepping stone.
Minor benefits:
- Cleaner
- Avoid re-allocating
- Faster lookup for `download`
Add more profiling traces
### What does this PR try to resolve?
Someone suggested I look at
[zed](https://github.com/zed-industries/zed).
It has some interesting performance characteristics compared to projects I looked at before:
- A lot of workspace members
- git dependencies
- patching with git dependencies
This adds traces that help provide more context for those scenarios when looking at them.
### How should we test and review this PR?
### Additional information
Some of these areas might be of interest for
optimizing:
- On every invocation, we do a git2 `copy_to` call for each git checkout
- On every invocation, we do a `du` on each git checkout
- It'd be great to avoid parsing every manifest in a git checkout but we need to do a full parse to make sure we find all packages (see https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Redundant.20code.20in.20.60GitSouce.60.3F)
- Its suspicious how much time we spend in the "poison" step of resolving when its a no-op
Someone suggested I look at
[zed](https://github.com/zed-industries/zed).
It has some interesting performance characteristics compared to projects
I looked at before:
- A lot of workspace members
- git dependencies
- patches
This adds traces that help provide more context for those scenarios when
looking at them.
Some of these areas might be of interest for
optimizing:
- On every invocation, we do a git2 `copy_to` call for each git checkout
- On every invocation, we do a `du` on each git checkout
- It'd be great to avoid parsing every manifest in a git checkout but we
need to do a full parse to make sure we find all packages (see
https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Redundant.20code.20in.20.60GitSouce.60.3F)
- Its suspicious how much time we spend in the "poison" step of
resolving when its a no-op
fix(overrides): Don't warn on duplicate packages from using '..'
### What does this PR try to resolve?
As part of #10752, I was changing the "duplicate package" warning to be like:
```
[WARNING] skipping duplicate package `a2 v0.5.0 ([ROOT]/foo/b/../a)`:
[ROOT]/foo/b/../a/a2/Cargo.toml
in favor of [ROOT]/foo/a/a2/Cargo.toml
```
and it showed that we were considering two paths to the same package to be duplicates.
This suppresses that warning.
### How should we test and review this PR?
### Additional information
I was changing the "duplicate package" warning to be like:
```
[WARNING] skipping duplicate package `a2 v0.5.0 ([ROOT]/foo/b/../a)`:
[ROOT]/foo/b/../a/a2/Cargo.toml
in favor of [ROOT]/foo/a/a2/Cargo.toml
```
and it showed that we were considering two paths to the same package to
be duplicates.
This suppresses that warning.
fix: Ensure dep/feature activates the dependency on 2024
### What does this PR try to resolve?
Fixes#14016
### How should we test and review this PR?
This doesn't revert the last commit of #14018 so that it works properly
on Editions 2021 and 2024.
### Additional information
