rust
/
rfcs
mirror of https://github.com/rust-lang/rfcs
1
0
Fork 0
Code Issues Releases Wiki Activity

fix(ref): Promote report on every command from alt to ref, but keep it deferred

This commit is contained in:
Ed Page 2024-01-23 20:19:53 -06:00
parent 6c17440443
commit 0bc42a8541
1 changed files with 25 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
text/3537-msrv-resolver.md
View File

@ -509,6 +509,30 @@ We expect the notice to inform users of these options for allowing them to upgra
Those flags will also be added to `cargo generate-lockfile`
## Syncing `Cargo.toml` to `Cargo.lock` on any Cargo command
In addition to the `cargo update` output to report when things are held back (both MSRV and semver),
We can attempt to have resolves to call out the new dependency versions that were held back from MSRV or semver.
Whether we do this and how much will be subject to factors like noisy output, performance, etc.
Implementation ideas...
We then do a depth-first diff of the trees, stopping and reporting on the first different node.
This would let us report on any command that changes the way the tree is resolved
(from explicit changes with `cargo update` to `cargo build` syncing `Cargo.toml` changes to `Cargo.lock`).
We'd likely want to limit the output to only the sub-tree that changed.
If there wasn't previously a `Cargo.lock`, this would mean everything.
We could either always do the second resolve or only do the second resolve if the resolver changed anything,
whichever is faster.
Its unknown whether making the inputs available for multiple resolves would have a performance impact.
While a no-change resolve is fast, if this negatively impacts it enough, we
could explore hashing the resolve inputs and storing that in the lockfile,
allowing us to detect if the inputs have changed and only resolving then.
## `cargo add`
`cargo add <pkg>` (no version) will pick a version requirement that is low
@ -633,25 +657,6 @@ When there still isn't an MSRV set, the resolver could
- This runs into quality issues with version requirements that are likely too low for what the package actually needs
- For dependencies that never set their MSRV, this effectively switches us from maximal versions to minimal versions.
## Reporting
Alternative to or in addition to the `cargo update` output to report when things are held back (both MSRV and semver),
we can run the resolver twice on the original input, once for MSRV and once without.
We then do a depth-first diff of the trees, stopping and reporting on the first different node.
This would let us report on any command that changes the way the tree is resolved
(from explicit changes with `cargo update` to `cargo build` syncing `Cargo.toml` changes to `Cargo.lock`).
We'd likely want to limit the output to only the sub-tree that changed.
If there wasn't previously a `Cargo.lock`, this would mean everything.
We could either always do the second resolve or only do the second resolve if the resolver changed anything,
whichever is faster.
Its unknown whether making the inputs available for multiple resolves would have a performance impact.
While a no-change resolve is fast, if this negatively impacts it enough, we
could explore hashing the resolve inputs and storing that in the lockfile,
allowing us to detect if the inputs have changed and only resolving then.
## Configuring the resolver mode on the command-line or `Cargo.toml`
The Cargo team is very interested in [moving project-specific config to manifests](https://github.com/rust-lang/cargo/issues/12738).
@ -824,6 +829,7 @@ Some options include:
- `current` is like `latest` but a little softer and might work
Whether we report stale dependencies only on `cargo update` or on every command.
See "Syncing `Cargo.toml` to `Cargo.lock` on any Cargo command".
# Future possibilities
[future-possibilities]: #future-possibilities