Config support for controlling MSRV-aware resolver

[epage]

Split out of #9930 for RFC #3537 for a more focused conversation

We need a config field but this was left undefined in the RFC

[epage]

The RFC proposed

[build]
resolver.precedence = "rust-version"  # Default with `v3`

with the following values (on first release)

• maximum
• rust-version (falls back to rustc version if not present)

Future possibilities

• Dependencies resolution with --minimal-versions #5657 could add a minimum
• rustc for saying to resolve to the rustc version
• In the future, people might want to specify specific versions (Generate "Cargo.lock" for old Rust compiler #13503)

[epage]

For rustc value, I think we should see how to align with the package.rust-version = "tbd" field so people can connect the dots more easily.

Like with term (#13337), I wonder if we should be doing more individual fields rather than be-all fields.

Something like:

[resolver]
maximum = <true|false>
rust-version = <true|false|manifest|toolchain|<X>.<Y>.<Z>>
# yanked = <allow|ignore>
# prerelease = <allow|ignore>

This would also give control over #13290, #4225

We can have a separate [install.resolver]

Thoughts

• I'd prefer more consistency in field names and values
• I'd like to cover cases of "deny <incompatible|yanked|prerelease>", "discourage <...>", "allow <...>"
• To satisfy the above two, i suspect we should break out the "max rust version" from the "rust version policy" fields

This leads to something like

[resolver]
maximum = <true|false>
incompatible-rust-version = <deny|discourage|allow>
yanked = <deny|discourage|allow>
prerelease = <deny|discourage|allow>

rust-version = <workspace|toolchain|<X>.<Y>.<Z>>

• Not thrilled with the names
• Not liking the location of rust-version as it should also apply to cargo add (but not cargo check?)
  • Maybe [build] could have its own rust-version field
  • Maybe we could call this table [dependencies] and have it apply to cargo add?

[epage]

I wonder if, instead of maximum = <true|false> with minimum being what you get with maximum = false, if it'd be better to have a <something> = <maximum|minimum>.

[epage]

Talking this through with @Eh2406

• Fewer fields offers a higher level experience with a combinatoric problem
• More fields offers a lower level experience, allowing people to build what they want, but some combinations might not make sense

There isn't really much pushing us one direction or the other, so one way to look at this is which way is easier to evolve. Having fewer fields makes it so we can change it so that field sets defaults on the others. Having more fields makes that a little messier.

Current proposal

[resolver]
precedence = "<maximum|rust-version>"
# precedence = "<maximum|rust-version|minimum>"
# future: rust-version = "<workspace|toolchain|<X>.<Y>.<Z>"

[epage]

We talked about this in the Cargo team meeting today.

We lean away from resolver.precedence / resolver.policy because

• It will quickly run into scaling issues
• It reads a little funny to have maximum and rust-version as mutually exclusive

When it came to resolver.rust-version, the biggest concerns were

• Naming that aligns with potential future expansion
• How to name the new resolver behavior of using incompatible-rust-version as a "last resort"

We leaned towards resolver.incompatible-rust-version

• Right polarity for potential other fields
• Keeps it distinct from setting a "resolve to rust version" field
• Expands to support rejecting of incompatible rust version package versions in the future

For the resolver.incompatible-rust-version field, we have three potential states

• "treat like everything else" (current behavior)
• "use if no other option" (new behavior)
• "use only if already in lockfile" (not planned atm)

Potential names for "use if no other option" include:

• discourage
• eschew
• avoid
• fallback

Fallback seems like just the right weight. The challenge is that its a
noun while other words we are considering are verbs (allow, deny).

[epage]

Goal: provide field values for

[resolver]
incompatible-rust-version = "<field>"  # can be one of two meanings for now, expandable to three

Stepping back to more fundamentals and playing a game of mad libs...

We need to pick one specific version of a software package from among many

• candidates
• potential deps
• options
• prospects
• nominees

Some of these "candidate" versions of the package will be

• filtered out
• ignored
• rejected
• denied
• disallowed

After that, we then choose the highest priority package from among "candidates". We aren't wanting to have users manually specify the priority order but just to say whether we

• ignore
• are agnostic of
• allow
• treat as "normal", "standard"

certain traits or if certain traits are

• discouraged
• eschewed
• avoided

when no other option is available. Or in other words, these are "fallback" versions

We should also put these in a sentence with the trait

• packages with "incompatible rust versions" are ...
• ... packages with "incompatible rust versions"

Examples

1. allow, deny, fallback

• "allow packages with incompatible-rust-versions"
• "deny packages with incompatible-rust-versions"
• "fallback to packages with incompatible-rust-versions"