Two tests were using `.rust_version("1.90.0")` for a "newer" Rust, but
this failed in rust-lang/rust#142792 for the start of the *real* 1.90.0.
Let's bump that to 1.999.0 so we won't have to deal with it for a while.
With 2024 stabilized, there will be a "first supported" version which is
above the versions used in tests.
In particular, for the `cargo install` test, we can't test the scenario
until a couple of versions have passed.
We have to rely on Edition 2024 changing ony resolver v3 which is
already covered.
This includes
- `cargo generate-lockfile --ignore-rust-version`
- `cargo update --ignore-rust-version`
This does not include
- `edition = "2024"`
- `resolver = "3"`
We do this by resolving for a package version that is compatible
with the most number of MSRVs within a workspace.
If a version requirement is just right, every package will get the
highest MSRV-compatible dependency.
If its too high, packages will get MSRV-incompatible dependency
versions.
This will happen regardless of what we do due to the nature of
`"fallback"`.
If its too low, packages with higher MSRVs will get older-than-necessary
dependency versions.
This is similar to the "some with and without MSRV" workspaces.
When locking dependencies, we do report to users when newer MSRV/SemVer
compatible dependencies are available to help guide them to upgrading if
desired.
Fixes#14414
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.
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
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.
In discussin this in #13873, it highlighted that we need to make sure we
tell people when we get in this state.
I decided to keep "latest" and "required rust version" messages mutually
exclusive to avoid too much noise. I gave "required rust version"
higher precedence as its the more critical to operation and, if you are
using an MSRV-incompatible package, it likely is "latest" already.
I was tempted to change colors to make "required rust version" stand out
from "latest" but was unsure what direction to go, so I held off.
Options included
- red for "required rust version", yellow for "latest"
- yellow for "required rust version", nothing for "latest"
There is also more discussion on how to format "latest" at #13908.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
This is a part of #13540 which is a party of #9930.
The config is `resolver.something-like-precedence` with values:
- `something-like-maximum` (default)
- `something-like-rust-version`
This is punting on the actual config schema so we can implement
`package.resolver` and `edition = "2024"` support as we want the
MSRV-aware resolver available without `cargo_features`.
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
In #9930, it recommended improving the error for incompatible packages
so people can better get to the root of the problem.
For example, you might get an error about `clap_lex` but resolving the
error for the higher level `clap` could make the problem with `clap_lex`
go away.
Because I generally saw earlier packages in the graph reported, I
assumed we were reporting these errors bottom up.
It turns out, we are reporting them in the `UnitGraph`s order, which is
non-deterministic because it is built on a `HashMap`.
So this adds determinism and shows all incompatible dependencies
(not just the bottom or the root).
This is a first step.
We might find that we still want to only include the shallowest units,
rather than all.
At that point, we can add the complexity to address this by walking the
unit graph.
We could also further improve this by querying the index to suggest
compatible versions of packages.
