-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Re-enable target-based dependency resolution #3121
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
Closed
neonichu
wants to merge
3
commits into
swiftlang:main
from
neonichu:reenable-target-based-dependency-resolution
Closed
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit of a blunt instrument, but it should yield correct results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This single line fixes the top secret errors that were reported?
I’m curious if the errors occur generally during fresh resolution, or if they only occur in the presence of a pins file?
I ask because the way I implemented the filtering, manifests < 5.2 asked for every dependency product from every package. Essentially that meant any package that might contain the intended dependency would be resolved. The intent was that if a 5.1 manifest depends on a package that later gets a minor version bump with a 5.2 manifest, that transitive 5.2 manifest knows which of its products were actually requested and can therefore meaningfully filter its own dependencies. What occurs to me know is that had a side effect of culling some dependencies in a way that is logically valid, but not stable compared to previous treatment of 5.2 manifests.
For example, consider the case of a 5.2 manifest which declares a slew of package dependencies, but its actual targets declare no dependencies whatsoever. Under a 5.1 toolchain, all those dependencies were resolved. Under the initial filtering algorithm, all those dependencies were ignored. Ignoring them is valid as far as the build process is concerned. However, because it produces different pins, it introduces an instability where old and new toolchains would each be insisting that the other’s pins are invalid.
Can you look into it to see if this seems to be the real problem, or at least if it is the deciding factor that channels execution into the problematic code branch. If so, then the correct solution is to change the handling of pre‐5.2 manifests to request absolutely everything absolutely all the time.
Such a fix would be done most cleanly here, right where it originates, by injecting something like this:
From that simple change, everything else should cascade back into place such that manifests from 5.1 and earlier are always and everywhere treated exactly as they were by the 5.1 toolchain. It would mean some graph pruning opportunities would missed, but it would ensure pin stability. Those missed optimizations would only effect old manifests, which presumably will become less and less common over time anyway. (5.2 manifests and above would still be properly skipping everything that isn’t used.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue I have been seeing is that we can miss dependencies of 5.1 and earlier packages that are actually required, the scenario is the same package being required by multiple different packages transitively. I need to dig in a bit more, I put this up more as a straw man so that we have some solution to reactivate target-based dependency resolution that we can land in 5.4.
Where I am at right now, I'm seeing that we don't download a few dependencies as part of resolution which leads us to not being able to include them later on here. This piece of code in
Workspace
is kind of subtle, because unless we have previously fetched a given package, we'll just fail and ignore it. I'll report back once I have more.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that makes sense.
I still think moving the workaround to the
Manifest
type like I suggested would be more consistent. I don’t thinkRepositoryPackageContainer
should alter the resolution strategy, as it won’t apply to other conformers of thePackageContainer
protocol.That sounds like there is another place in need of a similar fix to this part of #3006. If a
topologicalSort
or similar graph traversal uses a node definition of just the package—instead of the package–filter pair—then it would think it had already visited that node and neglect to look at its dependencies even if the filter is different the second time the node shows up. The result would be exactly the symptoms you describe.