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.

Sign up for GitHub

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

Jump to bottom

Two fixes to constraint solving #16353

Merged
merged 2 commits into from
Nov 18, 2022
Merged

Two fixes to constraint solving #16353

merged 2 commits into from
Nov 18, 2022

Commits on Nov 16, 2022

  1. Fix replace operation 

    In OrderingConstraint#replace we moved the actual replacement
of a parameter with a type from the start of replace to its end,
since that was more convenient for dependency adjustments. It turns
out that doing so causes infinite recursion in instantiations in
some cases, specifically if a parameter contains itself as an indirect
lower bound that goes through an alias. Here is a situation that arises
in i16311.scala:
```
type WithTag[T, U] = T & Tagged[U]

  T1 >: WithTag[T2, Int]
  T2 >: T1 & Tagged[Int]
```
The current instantiation for T1 and T2 is Nothing. But we ran into a cycle
instead.

The fix is to move the parameter replacement back to the start of `replace`,
and to account for that in the dependency adjustment logic.

Fixes scala#16311
    @odersky
    odersky committed Nov 16, 2022
    Configuration menu
    Copy the full SHA
    0a88360 View commit details
    Browse the repository at this point in the history

  2. See through aliases before decomposing And/Or in isSubType 

    There seem to be two missing cases in TypeComparer where we
have a TypeParamRef on one side and an And/Or type under an aloas on the other.
Examples:

    type AND = A & B
    type OR  = A | B
    p <:< AND
    OR <:< p

In this case we missed the decomposition into smaller types that would happen
otherwise. This broke i16311.scala in Ycheck and broke i15365.scala with an
infinite recursion in avoidance.

I verified that having an AndType as super or subtype of an abstract type works
as expected. So if in the example above

    type AND >: A & B

or

    type AND <: A & B

it worked before. It was just aliases that were the problem (I assume it's the same for OrTypes
as lower bounds).
    @odersky
    odersky committed Nov 16, 2022
    Configuration menu
    Copy the full SHA
    c13cab0 View commit details
    Browse the repository at this point in the history