-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Comments
This was referenced Jul 12, 2015
Woops, I thought this was the mio repo |
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
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:The text was updated successfully, but these errors were encountered: