How to correctly find MSRV for subprojects?

[Guara92]

Hi,

I'm having some trouble to correctly check the MSRV specify in a subproject, in particular I have a CLI that use cargo msrv as a subprocess, and to test the CLI there are some example project inside test_projects/rust/ folder, one of those has this manifest:

[package]
name = "version_mismatch"
version = "0.1.0"
edition = "2021"
rust-version = "1.80.0"

if I do this:

cd test_projects/rust/version_mismatch
cargo msrv find --output-format minimal

the output is 1.85.1, if instead I move out the test project:

cp -r test_projects/rust/version_mismatch ../
cd ../version_mismatch
cargo msrv find --output-format minimal

the output is 1.80.1, so it seems that the parent Cargo.toml has the priority here, infact the CLI manifest specify edition="2024" that requires rust 1.85.1.
I tried to set --path=<version_mismatch_project_absolute_path and/or --ignore-lockfile but the result is always the same, is this behavior expected? Is there an option to ignore the parent manifest that I can use?

[foresterre]

How are the projects sublocated? Are they both in a Cargo workspace or is the sub project in a sub folder, but not in the workspace?

[foresterre]

Hi! no the project isn't a workspace, the project tree looks like:

.
├── Cargo.lock
├── Cargo.toml
├── README.md
├── rust-toolchain.toml
├── rustfmt.toml
├── src
│   ├──  lib.rs
│   ├──  ...
├── test_projects
│   └── rust
│       ├── msrv_violated
│       │   ├── Cargo.lock
│       │   ├── Cargo.toml
│       │   ├── rust-toolchain.toml
│       │   ├── rustfmt.toml
│       │   └── src
│       │       └── main.rs
...

That's likely the problem. Cargo (I think at least cargo metadata) has an undocumented 'breaking change', where from a certain edition, it would always try to find top level Cargo.toml manifest recursively instead of the one on your current path.

It caused various problems for me as I used to have similarly sublocated test crates, which prevented some edition updates at the time. I can try and find the related issues and PR's as they contain more details, but I'm almost certain that this is the problem.

For testing I now use assert_fs and its TempDir implementation, which you can see here, which is anyhow the better approach since it offers slightly better test case isolation.

[foresterre]

Are these sublocated rust projects test projects? Otherwise we can try to find whether we can work around the issue somehow.

[Guara92]

Thanks for your hints, probably I can use assert_fs to move the tests projects in a temporary dir as a workaround!
Yeah, basically those projects are used for the integration tests of the CLI, which is essentially an opinionated linter for Rust & golang projects.

[Guara92]

I can confirm that moving the test projects in temporary directories before testing the CLI actually solve the problem, thanks again for the suggestion!