Currently, users see some rather slim amount of log output (only fetch, check, and the result).

Investigate:

• What do we want to show to users?
• What libraries can we use?
  • https://github.com/Byron/prodash
  • tui-rs
  • crossterm

We do something pretty dumb right now: simply take the minor versions and decrease it. But we do have all versions available, even ordered already, so instead we should be slightly smarter and first build and index of available versions, and then for each latests available minor version run the check.

is there a reason this isn't the default?

Originally posted by @danieleades in #45 (comment)

For example using tracing which adds scopes and can be used to structurally log: https://tracing.rs/tracing/

Why?

• Debugging can be difficult when you're not sure where the program failed.
• We invoke certain external processes, and these are difficult to follow.
• Information which is useful for a maintainer / cargo-msrv developer is different from information shown to user.

are you also interested in using Clap's declarative syntax for defining the CLI?

Originally posted by @danieleades in #100 (comment)

By ignoring the lockfile, it will be regenerated for each run. The idea behind it is that we can have some compatibility for different lock file versions. However, even with a lockfile, a dependency version may be updated to a (hopefully semver compatible) version which falls within the semver requirements. If some dependency then introduces a change which breaks our MSRV, while Cargo pulls in a specified, newer, matching semantic version, we may still fail.

As an example: if we have an dependency A, with published versions 0.1 and 0.2, and our in-repo lockfile takes 0.1 while a newly generated lockfile may take 0.2 instead, and 0.2 has a higher MSRV than 0.1, then by removing the lockfile we our MSRV changes, which is a problem for MSRV verification.

Example failure run: https://github.com/foresterre/cargo-msrv/runs/3809534104#step:8:1

In this specific case, on Rust toolchain versions below 1.46 (our MSRV is 1.42), we get the following error:

error[E0658]: `while` is not allowed in a `const fn`
  --> /user/.cargo/registry/src/github.com-1ecc6299db9ec823/http-0.2.5/src/header/value.rs:85:9
   |
85 | /         while i < bytes.len() {
86 | |             if !is_visible_ascii(bytes[i]) {
87 | |                 ([] as [u8; 0])[0]; // Invalid header value
88 | |             }
89 | |             i += 1;
90 | |         }
   | |_________^
   |
   = note: for more information, see https://github.com/rust-lang/rust/issues/52000

For the --ignore-lockfile option itself, we'll need to figure out a strategy where we can convert between lockfile version, while keeping the versions in the Cargo.lock file the same. While in an ideal world, this error could have been prevented proper semver specifications, in the real world, such issues happen, and cargo-msrv should not overly rely on down-tree dependency specifications.

See rust-lang/rust#65262
Currently nightly only.

We currently always update the index. We should however make this optional (in which case the user bears the responsibility of having an up-to-date index in place at the right location on disk.

NB: the location on disk is currently not configurable, allowing for the location to be changed depends on foresterre/rust-releases#40

One of my projects is supported by Rust 1.30.0+, however cargo-msrv reports that the minimum version is 1.38.0.

If I manually run cargo check or cargo test with an earlier version:

$ cargo +1.37.0 check
error: failed to parse lock file at: /home/lucas/stringslice/Cargo.lock

Caused by:
  invalid serialized PackageId for key `package.dependencies`

It looks like the format of Cargo.lock has changed slightly between 1.37.0 and 1.38.0. If I delete Cargo.lock and rerun cargo check or cargo test it passes:

$ rm Cargo.lock
$ cargo +1.37.0 check
    Updating crates.io index
    Finished dev [unoptimized + debuginfo] target(s) in 2.94s

However, if I try this with cargo msrv it will first regenerate the Cargo.lock file with the latest stable Rust (currently 1.52.0), which then fails to parse when it gets to 1.37.0.

The only way I can get it to correctly report the correct MSRV is running with --maximum=1.37.0 so that it generates a Cargo.toml compatible with Rust<=1.37.0:

$ rm Cargo.lock
$ cargo msrv --maximum=1.37.0 --minimum=1.20.0 -- cargo test -- --test-threads=1
Determining the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo test -- --test-threads=1
   Finished The MSRV is 1.30.1
████████████████████████████████████████████████████████████████████ 00:00:28

The best solution I can think of is adding a --ignore-lock-file flag to move/delete Cargo.lock and let Cargo regenerate it with each toolchain version. This means gives the user the option of whether to use or ignore the lock file.

Improve the --help text for the --verify flag.

--verify
            Verify the MSRV, if defined with the 'package.metadata.msrv' key in the 'Cargo.toml'. When this flag is
            present, cargo-msrv will not attempt to determine the true MSRV. It will only attempt to verify specified
            MSRV, the Rust build passes similarly to regular cargo-msrv runs.

cargo publish --dry-run:
warning: manifest has no documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.

• Currently we install exact toolchain versions
• The latest stable version is simply stable, if installed as such
• Because rustup doesn't install that version with an exact version specifier, we can have two copies of the same toolchain; For example if the latest stable is 1.51.0, we get:
  • a stable toolchain (which was already installed)
  • a 1.51.0 toolchain (installed by cargo-msrv)

Since toolchain installation takes up significant time, it would be a good idea to reduce the installing of latest stable toolchain, even by one item; assuming it's available on the users system.

Re-design of CLI interface
==========================

why?

* too many option stacked below the primary command
* certain flags and options are irrelevant for certain actions
* improve clarity

redesign based on current:
--------------------------

cargo msrv
  --output human xor json
  --no-logging

cargo msrv list
  Lists the msrv's of all (transitive) dependencies, and computes the MSRV based on these values
  --include-dev
  --include-build
  --no-transitive
  --no-compute-msrv

cargo msrv verify
  Tests a crate against a given msrv 
.... file: Cargo.toml key: metadata.msrv
.... env: CARGO_MSRV_VERIFY   
.... arg: --msrv {}

  --on-error=(
    exit,
    msrv-run,
    cargo-check,
  )

--strategy (ast, toolchain, (db))

cargo msrv run (?)
  Determine the MSRV for the given crate
  --minimum or CARGO_MSRV_MINIMUM
  --maximum or ...
  --source SOURCE or ...
  --no-edit-cargo-toml or ...
  --beta xor --nightly
  --strategy (ast, toolchain)

cargo msrv install
	(no args) install [package.metadata.msrv] toolchain

cargo msrv pre-install-toolchain
	
	(list of versions) these versions
	(version range) 
	(expected bisection range)

   (Pre) install toolchains for current platform if necessary

longer term:
------------

cargo msrv submit
   Submit (vote) working versions to database

cargo msrv lookup 
  Attempts to look up the msrv of dependencies
  Uses Cargo.toml metadata.msrv or/and database
  As obtained sources by cargo

exported from notes

• requires --minimum <version> (default: Rust 1.31, first Rust edition 2018 version) and --maximum <version> (default: latest version)
• add a --search-strategy <name> (or just --strategy <name>) command
• perform a binary search for the MSRV, instead of the default linear searc

I am interested in publishing a (binary) package to AUR for this tool. To make this easier, it would be nice if (at least) a Linux build would be attached to each release.

Would you be open to adding a GitHub workflow that attaches a binary to each release? I am happy to submit a PR for that.

The Reporter was supposed to make everything effortlessly callable, and faster to compile, but did not have the hoped effect, as it makes it overly complicated to implement and access specific methods only for some Outputs (they now require either downcasting or an exposing trait implementation for all outputs).

Example: https://github.com/foresterre/cargo-msrv/pull/146/files#diff-ff3312d2455c0ecdc49cbaa4ac137a0258405ffb651767d633b942c02a530c16R32

i.e. currently we show:
cargo-msrv: checking target: <target> on version: <version>

however, during the check two steps take place:

• installing toolchain (for version-target) if not installed
• checking using the check command

It would be nice to show the status of each step separately.

• The linking step can be useful to check whether linking dependencies work with a certain version, however, since we specifically aim to check whether a Rust version is compatible, check should work well enough
• cargo check is a bit faster, especially for larger projects
• You can still use cargo build manually with cargo msrv -- cargo build or cargo msrv -- cargo build --all

The issue comes because rust-releases parses the Rust RELEASES.md without looking at the release date if it is in the future or not.

The current RELEASES.md starts like this,

Version 1.55.0 (2021-09-09)
============================
...

and rust-releases-rust-changelog/src/lib.rs#L42-L49 has this,

        let releases = content
            .lines()
            .filter(|s| s.starts_with("Version"))
            .filter_map(|s| {
                s.split_ascii_whitespace()
                    .nth(1)
                    .and_then(|s| semver::Version::parse(s).map(Release::new_stable).ok())
            });

PS. A workaround is to add --max 1.54.0 until 1.55.0 releases.

--edition <value>: reduces the search space to the Rust versions which provide support for a certain edition.

example:

--edition 2018 would include Rust versions >= 1.31.0

We currently fetch the channel manifest only once on the first run, unless the cached file is removed.
This behaviour is unwanted as we need to deal with changes (every new Rust minor version update). Thus we need to add the ability to download a new copy of the channel manifest.

One possibility is to use the directories crate (which is already included as dependency) and store a last checked on date in a file. Then we can take a delta time and if it is larger than some fixed duration (e.g. 1 day), we re-fetch the channel manifest and update the last checked date.

https://github.com/foresterre/cargo-msrv/blob/master/src/fetch.rs#L172

https://docs.rs/clap/2.33.0/clap/enum.AppSettings.html#variant.TrailingVarArg

• Find dependencies (e.g. cargo metadata or cargo guppy via cargo metadata)
• For each dependency:
  • read package.rust-version or else package.metadata.msrv
• select min(dependency min versions)

cargo msrv list
  Lists the msrv's of all (transitive) dependencies, and computes the MSRV based on these values
  --include-dev
  --no-transitive
  --no-compute-msrv

When we find a new MSRV, we should be able to add it to the Cargo manifest (Cargo.toml) automatically, saving a user time, similarly to cargo add etc. from cargo-edit.

By default:

• package.rust-version for Rust distributions where MSRV >=1.56
• package.metadata.msrv for Rust distributions where MSRV <1.56, as Cargo supports the rust-version field only since Rust distributions 1.56 or newer; for earlier versions it will produce an (unwanted) error.

TODO's:

• #139
• Add CLI option, along the lines of --write-manifest-msrv (feel free to suggest a better name :D) #368
• Write MSRV to the correct key, depending on the MSRV found

Under consideration:

• Consider adding a flag when overwriting an existing msrv, e.g. `--no-override-manifest-msrv
  • NB: this option needs to handle the two different places (package.rust-version and package.metadata.msrv) where we can put the MSRV
• Consider adding flag to always use package.rust-version regardless of the MSRV and warning Cargo will produce for versions <1.56.0.
• Consider adding flag to always use package.metadata.msrv regardless of the MSRV

Example 1:

Given, a found MSRV of version 1.56.0, and the following manifest:

[package]
name = "v_1_56_0"
version = "0.1.0"
authors = ["foresterre <[email protected]>"]
edition = "2021"

[dependencies]

We would write the the found MSRV to the manifest, and produce:

[package]
name = "v_1_56_0"
version = "0.1.0"
authors = ["foresterre <[email protected]>"]
edition = "2021"
rust-version = "1.56.0"

[dependencies]

Example 2:

Given, a found MSRV of version 1.55.0, and the following manifest:

[package]
name = "v_1_56_0"
version = "0.1.0"
authors = ["foresterre <[email protected]>"]
edition = "2021"

[dependencies]

We would write the the found MSRV to the manifest, and produce:

[package]
name = "v_1_56_0"
version = "0.1.0"
authors = ["foresterre <[email protected]>"]
edition = "2021"

[package.metadata]
msrv = "1.55.0"

[dependencies]

The command cargo check --all externally works, but says: Bad check for 1.55.0 and fails with the above message.

  eww on  current [$⇡] via  v14.17.2 via 🦀 v1.56.0-nightly took 1m40s >>> cargo check --all
    Checking eww v0.2.0 (/home/animesh/Projects/eww/crates/eww)
    Finished dev [unoptimized + debuginfo] target(s) in 10.64s

  eww on  current [$⇡] via  v14.17.2 via 🦀 v1.56.0-nightly took 10s >>> cargo msrv
Determining the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo check --all
   Done Bad check for 1.55.0      █░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 00:00:35
   Failed check command cargo check --all didn't succeed
Unable to find a Minimum Supported Rust Version (MSRV).

If you think this result is erroneous, please run: `cargo check --all` manually.

If the above does succeed, or you think cargo-msrv errored in another way, please feel free to
report the issue at: https://github.com/foresterre/cargo-msrv/issues

Thank you in advance!

Older Cargo versions do not support newer lock files.

When running cargo-msrv against a project with a newer Cargo lock file, but with an older toolchain version, the cargo binary in this toolchain distribution does not support the newer lock file.

As a result, cargo-msrv fails to find the true MSRV.

It can be solved in a number of ways:

1. Let the latest Cargo version invoke an older toolchain, instead of the toolchain included in the same distribution.

2. Convert between the lock file versions (potentially lossy)

3. Accept unfrozen versions for dependencies and ignore the lock file (the --ignore-lockfile option currently does this)

4. The currently WIP AST based analysis completely side steps this issue, but has the down (or up) side that tooling included in a Rust distribution is not taken into account. A question here is what the Rust in MSRV means (i.e. distribution, compiler or even spec if there was any). Regardless, if this analysis strategy will be added, the others won't be removed, so the problem will persist.

Currently (since #16), we'll always use the 'minimal' profile.

https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html

• Setting it when the msrv is found, and a flag is given (#328)
• #141
• Resolving from package set (new find msrv method)
• with above, limit search space

From 1.56.0

decent_toml_rs_alternative has so far served us well for reading TOML documents, but now we also want to write TOML to TOML files, and if we can manage it while preserving the document layout. This is possible if we switch to toml_edit.

This issue is an requirement for issue #138.

A Cargo.toml file can have it's edition specified.

For example, the edition of this project is specified here:
https://github.com/foresterre/cargo-msrv/blob/main/Cargo.toml#L7

[package]
edition = "2018"

If this edition is present (package.edition TOML key), we can use its value as the minimum version, similar to the --min option.

The Cargo.toml file can be read like this: https://github.com/foresterre/cargo-msrv/blob/main/src/lib.rs#L70-L77.

--

We should also add a flag to disable this behaviour: something along the lines of --no-read-min-edition.

For inspiration on how to add the argument: https://github.com/foresterre/cargo-msrv/pull/129/files#diff-b2812f19576dd53d0c35b107a322f58a00fce6977f4b5976e1961853982af3ccR137-R1411

--

The idea of this issue is similar to #104, except instead of taking --min as argument, it should read the version from the Cargo.toml.

• Read edition from Cargo.toml if present
• Set edition as minimum version
• Add option to disable this behaviour

We currently read the Cargo.toml manifest in both the config.rs, and separately in manifest.rs.
We should de-duplicate this behaviour.

Ideas:

• Add a LazyManifestReader, e.g. to the config, which handles reading the file lazily
• Add the reading of the package.edition field to manifest.rs.

To make the file reading lazy, we can use the OnceCell data structure from https://crates.io/crates/once_cell.

Dedup:
https://github.com/foresterre/cargo-msrv/blob/main/src/config.rs#L297-L311
https://github.com/foresterre/cargo-msrv/blob/main/src/manifest.rs#L21

I just tried the tool out and it doesn't work for me:

project-rs on  main [?] is 📦 v0.1.0 via 🦀 v1.51.0 took 12s
❯ cargo msrv
Determining the Minimum Supported Rust Version (MSRV) for toolchain x86_64-apple-darwin
Using check command cargo build --all
   Done red light for 1.51.0      █░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 00:00:01
   Failed check command cargo build --all didn't succeed
Unable to find a Minimum Supported Rust Version (MSRV).

If you think this result is erroneous, please run: `cargo build --all` manually.

If the above does succeed, or you think cargo-msrv errored in another way, please feel free to
report the issue at: https://github.com/foresterre/cargo-msrv/issues

Thank you in advance!

Running cargo check works and the exit code is 0.

rustc: rustc 1.51.0 (2fd73fabe 2021-03-23)
macOS: Big Sur 11.2.3 (20D91)

Is there supposed to be output for running cargo msrv? I tried it and followed along with htop as it worked backwards through rust versions, assuming that when it stopped at 1.44.0 that the last version supported was 1.45.0, but this gets a little confusing, especially if I'm working in multiple projects.

Is there something I missed?

• Currently we don't support beta and nightly versions, pending the upcoming rust-releases update.

• When running against the current cargo-msrv it will produce an error like: could not find a satisfying MSRV for project

• We should improve this error message, for the time being, until beta and nightly are supported

• Improve error message

Example of current output:

Minimum Supported Rust Version (MSRV).

If you think this result is erroneous, please run: `cargo check --all` manually.

If the above does succeed, or you think cargo-msrv errored in another way, please feel free to
report the issue at: https://github.com/foresterre/cargo-msrv/issues

Thank you in advance!

Split from #124 (comment)

I have a project where the MSRV for the tests is not the same as for the binary

• Paves the way to support nightly, when support in rust-releases becomes available
• Alleviates bugs like #94
• No source is perfect, or long-term guaranteed to work: having more sources means there's more likely one you will like

Available sources: https://docs.rs/rust-releases/0.16.0/rust_releases/#implemented-sources