Skip to content

cargo update -p SPEC can silently downgrade dependencies of other packages when multi-major ranges are used #5529

@ehuss

Description

@ehuss

This is kinda convoluted, but it bit me when I wasn't paying attention when updating rust's lock file. Here's a relatively small repro. Create a workspace with the following members and dependencies:

a → bitflags="0.9"
b → bitflags=">= 0.9, < 2.0"
c → bitflags="1.0"

cargo update will generate a lockfile that looks good (a→0.9, b→1.0, c→1.0).

cargo update -p c will downgrade b's copy of bitflags to 0.9! I'd expect it to leave it as-is.

The real-world example of this is in rust where these chains exist:

rustbook → ... → html5ever → .. → rand 0.3
rls → rayon → rayon-core → rand >=0.3, < 0.5
cargo → ... → rand 0.4

Updating cargo caused rayon's version of rand to downgrade. I didn't use rand in my example above because version 0.3 is a little odd in that it also depends on rand 0.4, but doesn't seem to be important and just complicates the example.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-dependency-resolutionArea: dependency resolution and the resolverCommand-updateS-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions