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

Public dependency refactor and re-allow backjumping #7361

Merged
merged 6 commits into from
Oct 1, 2019

Conversation

Eh2406
Copy link
Contributor

@Eh2406 Eh2406 commented Sep 13, 2019

There were three attempts at vanquishing exponential time spent in Public dependency resolution. All failures. All three started with some refactoring that seams worth saving. Specifically the data structure public_dependency that is used to test for Public dependency conflicts is large, tricky, and modified in line. So lets make it a type with a name and move the interactions into methods.

Next each attempt needed to know how far back to jump to undo any given dependency edge. I am fairly confident that any full solution will need this functionality. I also think any solution will need a way to represent richer conflicts than the existing "is this pid active". So let's keep the still_applies structure from the last attempt.

Last each attempt needs to pick a way to represent a Public dependency conflict. The last attempt used three facts about a situation.

  • a1: PublicDependency(p) witch can be read as the package p can see the package a1
  • b: PublicDependency(p) witch can be read as the package p can see the package b
  • a2: PubliclyExports(b) witch can be read as the package b has the package a2 in its publick interface.

This representation is good enough to allow for backjumping. I.E. find_candidate can go back several frames until the age when the Public dependency conflict was introduced. This optimization, added for normal dependencies in #4834, saves the most time in practice. So having it for Public dependency conflicts is important for allowing real world experimentation of the Public dependencies feature. We will have to alter/improve/replace this representation to unlock all of the important optimizations. But I don't know one that will work for all of them and this is a major step forward.

Can be read one commit at a time.

@rust-highfive
Copy link

r? @nrc

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 13, 2019
@alexcrichton
Copy link
Member

@Eh2406 would you like me to take over reviewing this? If so, anything else you'd like me to know before starting?

@Eh2406
Copy link
Contributor Author

Eh2406 commented Sep 24, 2019

Happy to have your revue! It is probably under documented, so guidance on what is confusing is helpful. The older commits are more clear benefits then the newer ones. If the new representation of a conflict requires long discussion then we can split this PR. Land the refactorings, and discuss the representation separately.

@bors
Copy link
Contributor

bors commented Sep 27, 2019

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

@Eh2406
Copy link
Contributor Author

Eh2406 commented Sep 27, 2019

Rebased

@alexcrichton
Copy link
Member

Sorry for taking awhile to get back to this. My eyes unfortunately still sort of glaze over when reading the resolver, so I think I'm sort of quickly becoming not able to review too much of the technical content of these sorts of changes to the resolver. That being said I trust you and this is a pretty sequestered part of the resolver, so I'm fine adding this in-tree and we can continue to iterate over time.

Again sorry for the delay, it takes me a long time to build up energy to dive into the resolver nowadays :(

@bors: r+

@bors
Copy link
Contributor

bors commented Oct 1, 2019

📌 Commit 0750caf has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2019
@alexcrichton alexcrichton reopened this Oct 1, 2019
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Oct 1, 2019

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Contributor

bors commented Oct 1, 2019

📌 Commit 0750caf has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Oct 1, 2019

⌛ Testing commit 0750caf with merge 8df2b21e7a303a9693db2fba78a191b207802777...

@bors
Copy link
Contributor

bors commented Oct 1, 2019

⌛ Testing commit 0750caf with merge 368333c...

bors added a commit that referenced this pull request Oct 1, 2019
Public dependency refactor and re-allow backjumping

There were **three** attempts at vanquishing exponential time spent in Public dependency resolution. All failures. All three started with some refactoring that seams worth saving. Specifically the data structure `public_dependency` that is used to test for Public dependency conflicts is large, tricky, and modified in line. So lets make it a type with a name and move the interactions into methods.

Next each attempt needed to know how far back to jump to undo any given dependency edge. I am fairly confident that any full solution will need this functionality. I also think any solution will need a way to represent richer conflicts than the existing "is this pid active". So let's keep the `still_applies` structure from the last attempt.

Last each attempt needs to pick a way to represent a Public dependency conflict. The last attempt used three facts about a situation.

- `a1`: `PublicDependency(p)` witch can be read as the package `p` can see the package `a1`
- `b`: `PublicDependency(p)` witch can be read as the package `p` can see the package `b`
- `a2`: `PubliclyExports(b)` witch can be read as the package `b` has the package `a2` in its publick interface.

This representation is good enough to allow for `backjumping`. I.E. `find_candidate` can go back several frames until the `age` when the Public dependency conflict was introduced. This optimization, added for normal dependencies in #4834, saves the most time in practice. So having it for Public dependency conflicts is important for allowing real world experimentation of the Public dependencies feature.  We will have to alter/improve/replace this representation to unlock all of the important optimizations. But I don't know one that will work for all of them and this is a major step forward.

Can be read one commit at a time.
@bors
Copy link
Contributor

bors commented Oct 1, 2019

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing 368333c to master...

@bors bors merged commit 0750caf into rust-lang:master Oct 1, 2019
@bors bors mentioned this pull request Oct 1, 2019
@Eh2406 Eh2406 deleted the public_dependency-as-type_4 branch October 2, 2019 20:09
bors added a commit to rust-lang/rust that referenced this pull request Oct 8, 2019
Update Cargo

To pull rust-lang/cargo#7482

List of merged PRs:
- Fix wrong directories in PATH on Windows (rust-lang/cargo#7482)
- Update SPDX list to 3.6 (rust-lang/cargo#7481)
- Mark Emscripten's .wasm files auxiliary (rust-lang/cargo#7476)
- Update `curl-sys` dependency requirement (rust-lang/cargo#7464)
- add dependencies for `pkg-config` (rust-lang/cargo#7443)
- Removing hash from output files when using MSVC (rust-lang/cargo#7400)
- Disable preserving mtimes on archives (rust-lang/cargo#7465)
- Removed redundant borrow (rust-lang/cargo#7462)
- Public dependency refactor and re-allow backjumping (rust-lang/cargo#7361)
- unify the quote in Cargo.toml (rust-lang/cargo#7461)
@ehuss ehuss added this to the 1.40.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants