[6.0][PubGrub] Narrow down cases when pre-release decisions are marked inv… #7808
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.
…alid
Explanation:
Pre-release decisions are valid if the derived range they were inferred from supports pre-release versions.
Currently, after deriving a pre-release assignment, the solver would assert
in some circumstances depending on order in which the dependencies are specified in the manifest.
This change makes it possible to infer pre-release verison of a package even when intermediate derivations did not support pre-release versions.
For example one package could declare
swift-syntax
dependency as508.0.1
..<601.0.0
and another could narrow it to600.0.0-latest
..<601.0.0
.Since the most constrained range in such case supports pre-releases a decision
to use the lastest pre-release version of
600.0.0
should be valid if thereis no
600.0.0
release yet.It's important to note that on each path a decision for a package is always
made based on the last undecided term's requirements which means - based on the current semantics - if such derivation doesn't support pre-release,
even though intermediate ones did, the solver would select a released version.
This PR is not aim to change that.
There is a caveat which we cannot narrowly fix - if package depends on an exact
pre-release version the inference is going to fail when there is another dependency
to the same package that doesn't support pre-releases. For example:
Package
A
depends on packagesB
andC
as follows:A
depends onB
=0.0.1-alpha
andC
=1.0.0
B
version0.0.1-alpha
has no dependenciesC
version1.0.0
depends onB
-0.0.1
..<0.0.2
In this situation the solver would fail because
0.0.1-alpha
does not satisfy range -0.0.1
..<0.0.2
inferred fromC
.Delays version decisions for packages with pre-release ranges until there are no more packages without pre-release versions. This also means that if a previous decision narrows down the range to releases-only the package would be made a contender on the next step of the solver.
Relaxes the
isValidDecision
check for pre-release decisions but makes sure that the last derivation supports pre-release versions.In situations like
InternalError
on packages with-latest
component in their version #7658 and InternalError: Expected root cause #7643 the solver would no longer assert and would produce a solution with a pre-release version forswift-syntax
.Main Branch PR: [PubGrub] Narrow down cases when pre-release decisions are marked invalid #7799
Risk: Low (These changes only affect packages that have pre-release version dependencies in a very narrow circumstances where there is another dependency that isn't a pre-release).
Reviewed By: @MaxDesiatov
Resolves: rdar://130112167
InternalError
on packages with-latest
component in their version #7658 InternalError: Expected root cause #7643Testing: Existing test-cases were modified and new tests were added.
(cherry picked from commit 43fd240)