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

Backtrack more aggressively when resolving #1804

Merged
merged 4 commits into from
Jul 17, 2015

Conversation

alexcrichton
Copy link
Member

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

@rust-highfive
Copy link

r? @wycats

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

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...

@alexcrichton
Copy link
Member Author

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:

  • Many functions are now on impl Context directly.
  • Many functions are tagged #[inline(never)] to limit the stack size of the recursive activate and activate_deps functions.
  • Documentation has been added for the module as a whole as well as the performance tricks currently in play
  • The Rust snapshot version has been updated as its LLVM apparently has a few optimizations Cargo needs to get those smaller stacks.

r? @brson

@rust-highfive rust-highfive assigned brson and unassigned wycats Jul 14, 2015
@bors
Copy link
Contributor

bors commented Jul 17, 2015

☔ The latest upstream changes (presumably #1812) made this pull request unmergeable. Please resolve the merge conflicts.

@brson
Copy link
Contributor

brson commented Jul 17, 2015

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
@alexcrichton
Copy link
Member Author

@bors: r=brson bcdb747

@bors
Copy link
Contributor

bors commented Jul 17, 2015

⌛ Testing commit bcdb747 with merge a10897c...

bors added a commit that referenced this pull request 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
@bors
Copy link
Contributor

bors commented Jul 17, 2015

@bors bors merged commit bcdb747 into rust-lang:master Jul 17, 2015
@alexcrichton alexcrichton deleted the aggressively-backtrack branch July 17, 2015 20:45
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 this pull request may close these issues.

failure to resolve with equality requirement.
5 participants