Skip to content

[6.0][PubGrub] Narrow down cases when pre-release decisions are marked inv… #7808

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

Merged
merged 1 commit into from
Jul 23, 2024

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Jul 22, 2024

…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 as 508.0.1 ..< 601.0.0 and another could narrow it to 600.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 there
    is 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 packages B and C as follows:

    A depends on B = 0.0.1-alpha and C = 1.0.0 B version 0.0.1-alpha has no dependencies
    C version 1.0.0 depends on B - 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 from C.

    • 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 for swift-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 #7643

  • Testing: Existing test-cases were modified and new tests were added.

(cherry picked from commit 43fd240)

…alid (swiftlang#7799)

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 as
`508.0.1` ..< `601.0.0` and another could narrow it to `600.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
there
is 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 packages `B` and `C` as follows:

`A` depends on `B` = `0.0.1-alpha` and `C` = `1.0.0`
`B` version `0.0.1-alpha` has no dependencies
`C` version `1.0.0` depends on `B` - `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 from `C`.

- 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
swiftlang#7658 and
swiftlang#7643 the
solver would no longer assert and would produce a solution with a
pre-release version for `swift-syntax`.

(cherry picked from commit 43fd240)
@xedin
Copy link
Contributor Author

xedin commented Jul 22, 2024

@swift-ci please test

@bnbarham bnbarham merged commit 31800c2 into swiftlang:release/6.0 Jul 23, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants