Fix elided lifetime
This fixes an issue with the recent nightly that has added a lint (https://github.com/rust-lang/rust/pull/129207) that warns about the lack of a lifetime, which looks like:
```
warning: elided lifetime has a name
--> src/cargo/core/workspace.rs:580:66
|
580 | pub fn default_members<'a>(&'a self) -> impl Iterator<Item = &Package> {
| -- lifetime `'a` declared here ^ this elided lifetime gets resolved as `'a`
|
= note: `#[warn(elided_named_lifetimes)]` on by default
```
chore(deps): update rust crate pasetors to 0.7.0
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [pasetors](https://togithub.com/brycx/pasetors) | workspace.dependencies | minor | `0.6.8` -> `0.7.0` |
---
### Release Notes
<details>
<summary>brycx/pasetors (pasetors)</summary>
### [`v0.7.0`](https://togithub.com/brycx/pasetors/blob/HEAD/CHANGELOG.md#070)
[Compare Source](https://togithub.com/brycx/pasetors/compare/0.6.8...0.7.0)
**Date:** August 28, 2024.
- Bump MSRV to `1.80`.
- Updated test vectors for `v3.public`.
- (*BREAKING*) Improved error-handling during claims validation. Added `Error::ClaimValidation(ClaimValidationError)`, where `ClaimValidationError` now further specifies the validation error ([#​131](https://togithub.com/brycx/pasetors/pull/131), credits: [`@​jpramosi](https://togithub.com/jpramosi)).`
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 5am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC41Ni4wIiwidXBkYXRlZEluVmVyIjoiMzguNTYuMCIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
This expands on #14461 to where only MSRV-compatible versions are
"actionable". MSRV-incompatible versions are therefore unstyled.
We report the MSRV needed so people can choose to unblock by updating
their MSRV. I had wondered if we should report the the absolute latest
MSRV-incompatible version or the one with the next higher MSRV from
where the user is at. Both are reasonable use cases, so I erred with
absolute latest version.
fix(resolve): With `latest` message, differentiate actionable updates
### What does this PR try to resolve?
Instead of always listing the absolutely latest version as a warning
color, we now differentiate
- compatible updates are always actionable
- incompatible, direct deps are always actionable
These get reported and made yellow while non-actionable messages are
unstyled.
### How should we test and review this PR?
I just used a broad stroke to say "compatible" in the message means "semver
compatible" and use `^`
- We could focus on "compatible with dependent version reqs" which is
what will be most actionable but seeing if we can get away without
having to track all in-coming version reqs.
- We could be more nuanced in language but the more verbose we are, the
more we take away from higher priority messages
### Additional information
This is not intended as *the* solution for #13908 though it experiments with what to do for that.
This is prep work for improved MSRV reporting where we will
differentiate this further by only considering MSRV-compatible updates as actionable
(or rustc-compatible when not using MSRV-aware reslver).
fix(pkgid): Allow open namespaces in PackageIdSpec's
### What does this PR try to resolve?
This is a part of #13576
This unblocks #14433. We have a test to ensure you can't publish a namespaced package and the error for that is getting masked in #14433 because the package name is getting parsed as a `PackageIdSpec` which wasn't supported until this PR.
### How should we test and review this PR?
### Additional information
feat(resolve): Report incompatible-with-rustc when MSRV-resolver is disabled
### What does this PR try to resolve?
This builds on #14457 to report when deps are incompatible with rustc when an MSRV-aware resolver is not used.
This affects stable code.
### How should we test and review this PR?
### Additional information
Instead of always listing the absolute latest version as a warning
color, we now differentiate
- compatible updates are always actionable
- incompatible, direct deps are always actionable
These get reported and made yellow while non-actionable messages are
unstyled.
This is not intended as *the* solution for #13908 though it makes
improvements in that direction.
This is prep work for improved MSRV reporting where we will
differentiate this further by only considering MSRV-compatible updates as actionable
(or rustc-compatible when not using MSRV-aware reslver).
I just used a broad stroke to say "compatible" in the message means "semver
compatible" and use `^`
- We could focus on "compatible with dependent version reqs" which is
what will be most actionable but seeing if we can get away without
having to track all in-coming version reqs.
- We could be more nuanced in language but the more verbose we are, the
more we take away from higher priority messages
fix(resolve): Report incompatible packages with precise Rust version
### What does this PR try to resolve?
In #14401, we reported about MSRV issues as if we were the resolver. We can be smarter than that though and report precise MSRV information. This allows us to elevate the message from color from yellow to red.
This is also prep work for telling users when a newer, MSRV-compatible version of a package is available.
### How should we test and review this PR?
The report function I added is a little odd because a follow up commit will update it to report when a package is incompatible with rustc when the MSRV resolver is disabled and do this on stable.
### Additional information
This builds on #14445 to improve #14401
fix(resolve): Dont show locking workspace members
### What does this PR try to resolve?
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
### How should we test and review this PR?
### Additional information
This builds on #14440
Log details of failure if no errors were seen
### What does this PR try to resolve?
Crater has started (some time ago, though exact point is not known) to see failures in crates without logging an error. We're suspecting that there's something wrong in Cargo or rustc, but it's also possible that Crater itself is at fault. In any case, this should provide more details.
cc https://github.com/rust-lang/crater/issues/733
### How should we test and review this PR?
My hope is that this is reasonable to land without additional tests -- as-is, we expect it to never happen (there's even a debug assert later in the same code path) but it seems it *is* happening sometimes in the wild.
More helpful missing feature error message
The "none of the selected packages contains these features" error does not say which packages are selected, and does not say which packages do have the requested features.
If any package in the workspace has the requested feature (matching exactly), the error suggests selecting that package, instead of trying alternative spellings.
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
refactor(update): Prepare for smarter update messages
### What does this PR try to resolve?
This is to make it easier to
- Make #14401 path aware
- Work on #13908, depending on what is decided
- Improve the heuristics for when we show `Locking` messages
There are fixes along the way that were found by making the code more consistent in prep for consolidating it, mostly for #14401.
### How should we test and review this PR?
Along the way, some odd code structures are used for the sake of making the diff easier to follow. These get cleaned up towards the end
I didn't add tests for the fixes because of the code consolidation that happens that causes us to cover more real-world scenarios with fewer tests.
### Additional information
fix: -Cmetadata includes whether extra rustflags is same as host
### What does this PR try to resolve?
Fixes#14253
The root cause is described in <https://github.com/rust-lang/cargo/issues/14253#issuecomment-2299595480>:
> `-Ztarget-applies-to-host --config target-applies-to-host=false` make it possible to build two units for the same output directory with different rustflags (one with artifact/target rustflags, one with none/host rust flags). Those flags aren't included in the `-Cmetadata` hash which is used to disambiguate different versions of crates, resulting in a conflict. The actual error being produced appears to be the result of two invocations of `rustc` racing and clobbering each other…
While we don't hash RUSTFLAGS because it may contain absolute paths that
hurts reproducibility, we track whether a unit's RUSTFLAGS is from host
config, so that we can generate a different metadata hash for runtime
and compile-time units.
### How should we test and review this PR?
This hack is only enabled when `target-applies-to-host=false` and when compile kind is the host platform, so the shouldn't affect any stable behavior.
`-Ztarget-applies-to-host --config target-applies-to-host=false` make it
possible to build two units for the same output directory with different
rustflags (one with artifact/target rustflags, one with none/host rust
flags). Those flags aren't included in the `-Cmetadata` hash which is
used to disambiguate different versions of crates, resulting in a conflict.
The actual error being produced appears to be the result of two invocations
of `rustc` racing and clobbering each other.
While we don't hash RUSTFLAGS because it may contain absolute paths that
hurts reproducibility, we track whether a unit's RUSTFLAGS is from host
config, so that we can generate a different metadata hash for runtime
and compile-time units.
This builds on the prior work to consolidate everything, simplifying the
code and making it clearer what behavior differences exist between
change kinds.
