-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Backtrack more aggressively when resolving #1804
Conversation
r? @wycats (rust_highfive has picked a reviewer for you, use r? to override) |
Hm, maybe don't r+ just yet, want to test out on Servo to make sure this doesn't blow any stacks. It'd be unfortunate to have to switch to an explicit stack... |
69d2513
to
596fa60
Compare
Ok, I have overhauled this to include some more changes. This has evolved into a bit of a larger scale refactor of the resolution code, although most of the changes are just code movement. I can split out the literal code movement changes if it makes it easier to review. The other changes made are:
r? @brson |
☔ The latest upstream changes (presumably #1812) made this pull request unmergeable. Please resolve the merge conflicts. |
596fa60
to
8e9ce3a
Compare
r=me |
Previously the `cit` folder was placed in the root directory but this adds logic to ensure it stays within the `target` subdirectory.
Looks like the new LLVM version has optimizations which help out a good deal with the recursion faced in the resolver, so let's use that version instead!
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
8e9ce3a
to
13971b4
Compare
13971b4
to
bcdb747
Compare
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
☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-64 |
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