Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failure to resolve with equality requirement. #1800

Closed
danburkert opened this issue Jul 11, 2015 · 1 comment · Fixed by #1804
Closed

failure to resolve with equality requirement. #1800

danburkert opened this issue Jul 11, 2015 · 1 comment · Fixed by #1804

Comments

@danburkert
Copy link

Cargo fails to resolve a dependency with an equality requirement if a newer version is published.

Steps to reproduce: clone tokio-rs/mio@eed4855 and change the dependency on libc from "0.1.8" to "=0.1.8". cargo build fails with the following error:

failed to select a version for `libc` (required by `mio`):
all possible versions conflict with previously selected versions of `libc`
  version 0.1.9 in use by libc v0.1.9
  possible versions to select: 0.1.8
@carllerche
Copy link
Member

Woops, I thought this was the mio repo

@carllerche carllerche reopened this Jul 13, 2015
alexcrichton added a commit to alexcrichton/cargo that referenced this issue Jul 17, 2015
Resolving a dependency graph may involve quite a bit of backtracking to select
different versions of crates, but the previous implementation of resolution
would not backtrack enough.

Once a dependency is completely resolved it's possible that any number of
candidates for its transitive dependencies were left out of the resolution
process (e.g. we didn't hit them yet). These candidates were not previously used
for backtracking (because resolution overall of the dependency finished), but
this commit alters the implementation to instead consider these as candidates
for backtracking.

Architecturally this changes the code to CPS to pass around a `finished`
continuation to allow tweaking the behavior whenever a dependency successfully
resolves. The key change is then that whenever a candidate for a dependency is
activated, we ensure the recursive step for the rest of the graph happens as a
sub-call. This means that if *anything* in the recursive call fails (including
some previous up-the-stack resolution) we'll retry the next candidate.

Closes rust-lang#1800
bors added a commit that referenced this issue Jul 17, 2015
Resolving a dependency graph may involve quite a bit of backtracking to select
different versions of crates, but the previous implementation of resolution
would not backtrack enough.

Once a dependency is completely resolved it's possible that any number of
candidates for its transitive dependencies were left out of the resolution
process (e.g. we didn't hit them yet). These candidates were not previously used
for backtracking (because resolution overall of the dependency finished), but
this commit alters the implementation to instead consider these as candidates
for backtracking.

Architecturally this changes the code to CPS to pass around a `finished`
continuation to allow tweaking the behavior whenever a dependency successfully
resolves. The key change is then that whenever a candidate for a dependency is
activated, we ensure the recursive step for the rest of the graph happens as a
sub-call. This means that if *anything* in the recursive call fails (including
some previous up-the-stack resolution) we'll retry the next candidate.

Closes #1800
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants