test: add fixes in the sat resolver
### What does this PR try to resolve?
This is a follow-up of https://github.com/rust-lang/cargo/pull/14614.
### How should we test and review this PR?
Commit 1 removes duplicate variables in the sat resolver.
Commit 2 removes useless clones in the sat resolver.
r? Eh2406
fix(renovate): Switch matchPackageNames to matchDepNames
When talking to `@weihanglo` about #14703, it was noticed that `renovate` was ignoring `extractVersion` and `schedule` for [`MSRV:1`](cf53cc54bb/.github/renovate.json5 (L50-L53)) and [`MSRV:3`](cf53cc54bb/.github/renovate.json5 (L64-L67)). After a lot of digging into why that was happening, I figured out that it was caused by a [breaking change in `renovate@38`](https://github.com/renovatebot/renovate/releases/tag/38.0.0):
> **package-rules**: `matchPackageNames` and related functions no longer fall back to checking `depName`.
This change caused `renovate` to no longer apply the configuration from `packageRules` to `MSRV:1` and `MSRV:3` as the `customManagers` for both specified [`depNameTemplate`](cf53cc54bb/.github/renovate.json5 (L23)) which is no longer being read.
To fix this issue, I changed `matchPackageNames` to `matchDepNames`, which solved the issue when I was testing locally.
feat: Stabilize MSRV-aware resolver config
### What does this PR try to resolve?
This includes
- `cargo generate-lockfile --ignore-rust-version`
- `cargo update --ignore-rust-version`
This does not include
- `edition = "2024"`
- `resolver = "3"`
This is part of #9930
### How should we test and review this PR?
### Additional information
This is stacked on top of #14636. The commits for this PR start with the commit with a title that matches the PR title.
[FCP](https://github.com/rust-lang/cargo/pull/14639#issuecomment-2392172716)
Help with [patch.crates.io]
This catches a syntactical mistake in TOML that's easy to make by patching `[patch.crates.io]` instead of `[patch.crates-io]`.
```diff
error: failed to parse manifest at `Cargo.toml`
Caused by:
[patch] entry `crates` should be a URL or registry name
+ For crates.io, use [patch.crates-io] (with a dash)
Caused by:
invalid url `crates`: relative URL without a base
```
test: Migrate publish snapshotting to snapbox
### What does this PR try to resolve?
This is part of #14039 and allows snapshotting in more places.
### How should we test and review this PR?
### Additional information
`InMemoryDir` is taken from some experiments I've been doing in snapshot for filesystem assertions. That got held up because of design complexity but publish validation's needs are simpler than I was designing for.
fix(registry): `HttpRegistry` `block_until_ready` returns early when work is still pending
### What does this PR try to resolve?
`block_until_ready` is returning early when there are still pending transfers. This leads to extra restarts of the resolver, impacting performance.
In the existing implementation:
- `handle_completed_downloads` runs and there are no completed downloads
- `multi.perform()` is called and completes new downloads, with no pending transfers remaining
- Since there are no items `remaining_in_multi`, the function returns early
This fixes the issue by reordering the calls to `multi.perform()`, `handle_completed_downloads`, then the completion check.
### How should we test and review this PR?
A test is added that uses cargo's tracing to show the number of blocking calls. First commit shows existing behavior, second commit shows fix.
Originally based on the PR #14680 by `@x-hgg-x.` The ordering fix in this PR also avoids an additional `block_until_ready` call for retried failed downloads.
fix(resolver): avoid cloning when iterating using RcVecIter
### What does this PR try to resolve?
Follow up of https://github.com/Eh2406/pubgrub-crates-benchmark/issues/6#issuecomment-2408905423.
This PR modifies the internal `RcVecIter` struct so that we can iterate on its items without cloning them. This improves performance of the resolver because eagerly cloning `Arc<T>` is not free.
Comparison of performance using `solana-core = "=1.0.5"` in `Cargo.toml`:
| branch | duration |
|------------|----------|
| master | 213s |
| PR | 202s |
r? Eh2406
docs: More information on what is and isn't included by cargo package
<!-- homu-ignore:start -->
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide" first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its title.
* It's ok to use the CI resources to test your PR, but please don't abuse them.
-->
### What does this PR try to resolve?
Add more detail to `cargo package` explaining what is and isn't included.
This doesn't add the feature requested by #11203 (shipping symlinks) but it does at least make it more clear that it's not supported.
### How should we test and review this PR?
Docs only change.
I wrote this by reading [src/cargo/sources/path.rs](82c489f1c6/src/cargo/sources/path.rs), in addition to my observations of cargo behavior, so it might be helpful for reviewers to check the new docs against the code.
fix(resolver): share conflict cache between activation retries
### What does this PR try to resolve?
Found in https://github.com/Eh2406/pubgrub-crates-benchmark/issues/6.
Currently the resolve is done in a loop, restarting if there are pending dependencies which are not yet fetched, and recreating the conflict cache at each iteration.
This means we do a lot of duplicate work, especially if the newly fetched dependencies has zero or few dependencies which doesn't conflict.
This also means that the maximum depth of the dependency graph has a big impact on the total resolving time, since adding a dependency not yet seen means we will restart the resolve at the next iteration.
Here is the output of the resolve for the master branch using `solana-core = "=1.2.18"` in `Cargo.toml`, printing the duration from the start after each iteration:
```
Updating crates.io index
103.142341ms [=====> ] 1 complete; 0 pending
118.486144ms [========> ] 2 complete; 0 pending
785.389055ms [===========> ] 62 complete; 0 pending
4.916033377s [==============> ] 277 complete; 0 pending
9.13101404s [=================> ] 439 complete; 0 pending
50.083251549s [====================> ] 520 complete; 0 pending
133.401303265s [=======================> ] 561 complete; 0 pending
214.120483345s [==========================> ] 565 complete; 0 pending
294.180677785s [=============================> ] 566 complete; 0 pending
Locking 536 packages to latest compatible versions
```
To improve the situation, this PR moves the conflict cache outside the activation loop so it can be reused for all iterations.
This is possible since when using an online registry, dependencies which are not yet fetched are not added to the candidate summary:
82c489f1c6/src/cargo/core/resolver/dep_cache.rs (L248-L266)
On the other hand, if a dependency query returns `Poll::Ready`, then all compatible summaries are returned, so we cannot have a partial view where only some compatible summaries would be returned. This means we cannot add a conflict in the cache which would be incompatible with future fetches, and therefore the conflict cache can be shared.
Here is the output of the resolve with this PR:
```
Updating crates.io index
98.239126ms [=====> ] 1 complete; 0 pending
127.528982ms [========> ] 2 complete; 0 pending
821.601257ms [===========> ] 62 complete; 0 pending
4.67917132s [==============> ] 277 complete; 0 pending
5.933230172s [=================> ] 431 complete; 0 pending
14.74321904s [====================> ] 508 complete; 0 pending
24.607428893s [=======================> ] 546 complete; 0 pending
24.700610469s [==========================> ] 550 complete; 0 pending
24.757651875s [=============================> ] 551 complete; 0 pending
Locking 536 packages to latest compatible versions
```
Besides the huge performance savings between iterations, sharing the conflict cache has the side effect of eliminating dead paths earlier in the resolve after a restart. We can see that the duration of all iterations using this PR is less than the duration of the last iteration on master, and that it needs to resolve less dependencies overall.
