IIUC right now Cargo ignores resolver.incompatible-rust-versions provided in Cargo.toml. Adding it results in the following warning:
warning: /my/project/Cargo.toml: unused manifest key: resolver
It means that I have to create .cargo/config.toml in repository just for it. Considering that we can select resolver version using workspace.resolver, I think we should be able to change its behavior in the same file.
cc @epage
This was covered in the RFC, see 3537-msrv-resolver - The Rust RFC Book
btw config and manifests are two very different formats that serve different purposes and operate at different levels of abstraction. One cannot assume that something in one will be mirrored in the other.
I did not say that I expect everything from config to be mirrored in manifest. I am saying that I expected to be able to set resolver mode in project's manifest similarly to the resolver version. The current state is simply inconsistent.
During the RFC discussion I tried to convey the approach which I want to use in my repositories (which usually contain one workspace with a number of crates): commit Cargo.lock with latest semver-compatible versions generated for current stable and test CI for MSRV and minimal versions by re-generating Cargo.lock for the tested crate. With resolver mode being defined in the workspace manifest I can easily develop with latest dependencies without swearing on each re-generation of Cargo.lock because I forgot to pass the CLI option. And in CI I can easily run MSRV and minimal versions tests by simply deleting the workspace's Cargo.toml. It also properly works with crates in the repo having different rust-versions.
Honestly, I am really disappointed with how the MSRV-aware resolver is handled... To me it looks like you have some "blessed" scenarios in mind, while everything else gets either ignored or gets subpar treatment.
As for the objections in the link:
But we want
cargo installto use the latest dependencies so people get bug/security fixes
I thought that workspace settings (such as the workspace section) are ignored and not included into generated Cargo.toml. What prevents cargo from ignoring the resolver section as well?
This gets in the way of “Extended published MSRV w/ latest development MSRV” being able to change it in CI to verify MSRV and “Extended MSRV” being able to change it in CI to verify latest dependencies
How in the world does it get in the way if the default resolver mode is to generate MSRV-compatible dependency tree?? Setting the alternative esolver mode globally (i.e. in .cargo/config.toml) would mean constant Cargo.lock conflicts between those who use it and those who don't. While committing it into repository would often mean that we have to create a .cargo directory just for this setting.
Many people do view the files interchangeably so I included that for compleetness, especially since you framed this around dropping the [resolver] table as-is.
Not blessed but higher priority. This was covered in the motivation section. There are many workflows with competing needs so I evaluated each workflow and prioritized them for which workflows would win out when a conflict arose.
As for the objections in the link:
Note that I am not going to engage with an exploration of solving this. The first part of the RFC has barely hit stable, we need more time to evaluate it and the [resolver] table and I have many other demands on my time that I put as a higher priority than working this out.
That said, I will clarify some aspects of cargo itself.
workspace.resolver is injected into published Cargo.toml files. Some projects require that to be set to build. There has been talk of doing similar for [profile].
Config is for transient or contextual settings. Manifests are for static settings. resolver = "3" changes a default. If instead we had resolver.incompatible-rust-versions = "allow", that is static and not changing a default. Likely the way forward is to define this as layered but with the other concerns that wasn't something i was going to explore at the time of writing the RFC.