cargo update should print warnings for incompatible candidates

[ehuss]

Currently, if there is a new release of a package that removes a required feature, then cargo update will silently do nothing. This can be a confusing experience because if the user looks at crates.io and sees there is a newer version, it can be difficult to understand why it is not working.

I believe that removing a feature is a breaking semver change, but not everyone knows this or is diligent about managing correct version bumps.

I think cargo update should display a warning if the "newest" candidate is not used because it is missing a feature.

It should probably ignore intermediate candidates, for example starting from version 0.1.0, publish bad release 0.1.1, publish fixed release 0.1.2, then updating from 0.1.0 to 0.1.2 should not produce any warnings.

There are other edge cases to handle (like being able to update from 0.1.0 to 0.1.1, but not 0.1.2).

The following is a test to demonstrate the scenario. The warning at the bottom is just a suggestion, the actual warning will likely be a little different.

#[cargo_test]
fn update_with_missing_feature() {
    // Attempting to update a package to a version with a missing feature
    // should produce a warning.
    Package::new("bar", "0.1.0").feature("feat1", &[]).publish();

    let p = project()
        .file(
            "Cargo.toml",
            r#"
            [package]
            name = "foo"
            version = "0.1.0"

            [dependencies]
            bar = {version="0.1", features=["feat1"]}
            "#,
        )
        .file("src/lib.rs", "")
        .build();
    p.cargo("generate-lockfile").run();

    // Publish an update that is missing the feature.
    Package::new("bar", "0.1.1").publish();

    p.cargo("update")
        .with_stderr(
            "\
[WARNING] a newer version of package `bar` is available (`0.1.1`), \
but it does not include the required feature `feat1`, so it will not be updated
",
        )
        .run();

    // Publish a fixed version, should not warn.
    Package::new("bar", "0.1.2").feature("feat1", &[]).publish();
    p.cargo("update")
        .with_stderr(
            "\
[UPDATING] `[..]` index
[UPDATING] bar v0.1.0 -> v0.1.2
",
        )
        .run();
}

[niedzielski]

Extending the "incompatible candidates" criteria, cargo update only considers dependencies that are permitted by the semantic version specified (often in the Cargo.toml). This means that newer forbidden dependencies are not reported and the caller is never made aware that a more involved upgrade is necessary to use the latest and greatest. E.g., consider

[dependencies]
foo = '0.2.1'

cargo update would report that a foo v0.2.2 was available but not v1.0.0. In large Cargo.toml files, this is problematic as there may be many dependencies and it's not practical to determine whether all are fully updated or not.

[ehuss]

@niedzielski although that is a similar issue, semver-incompatible notifications are part of #4309. You can use the cargo-outdated tool for that.

[niedzielski]

@ehuss, very helpful. Thank you! 👍

[epage]

We now report when a non-latest dependency is selected in #13372 but we don't

• Report the latest compatible
• Provide a message saying why it was withheld.