Panicked on new platforms (like riscv64gc) if MSRV is too old about cargo-msrv HOT 5 OPEN

Full test log: cargo-msrv-0.15.1-3-riscv64-check.log

from cargo-msrv.

These are all integration tests, which depend on Rustup being able to install the older toolchains.

Ideas to resolve the issue:

• disable the subset of integration tests for riscv64gc
• port tests to use newer versions, in a manner such that the minimum accessed version would be Rust 1.47.0

What do you think the best course of action would be?

from cargo-msrv.

@foresterre I haven't read the code carefully, but I think there should be a way to distinguish if the installation failure is caused by the specified target not existing or any other error.

I think skipping all non-existent target errors is a good solution (provided at least one version is installed successfully) so that we can avoid maintaining a minimum support version table for each new architecture.

from cargo-msrv.

In my opinion, cargo-msrv should try to find the minimum supported version binary for a specific arch. Different MSRV on different architecture is more acceptable. We can't ask a developer who working on RISC-V to follow the MSRV generated from x86_64.

For example, if there is a new architecture implementation coming in Rust 1.999999 or whatever, developer will not able to compile some crate with rustc v1.999998, so the MSRV for that architecture should be 1.999999.

from cargo-msrv.

In my opinion, cargo-msrv should try to find the minimum supported version binary for a specific arch. Different MSRV on different architecture is more acceptable. We can't ask a developer who working on RISC-V to follow the MSRV generated from x86_64.

For example, if there is a new architecture implementation coming in Rust 1.999999 or whatever, developer will not able to compile some crate with rustc v1.999998, so the MSRV for that architecture should be 1.999999.

I agree.

Cargo itself explicitly states that the rust-version key in the Cargo manifest affects all targets in the package. That is, only one MSRV can be set for a package (if you want 'official cargo support').

For a tool like cargo-msrv however, it may very well be desirable to search for the MSRV independently for each target, and maybe optionally set the MSRV per target specifically. It would then be up to the crate developer to decide which MSRV to pick from the set of MSRV's per target (assuming no target will be removed, this might always be the highest MSRV in the set).

from cargo-msrv.