Be still more careful when computing denotations of class parameters #16112
Conversation
This file contains 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
Be still more careful when intersecting info and arguments of a class type parameter.
This is the latest installment of a never-ending story.
The problem is this: Given
```scala
class C[T >: L1 <: H1] { val x: T }
def f(): C[? >: L2 <: H2]
```
what is the type of `f().x`?
With capture conversion (an extremely tricky aspect of the type system forced on us
since Java does it), the type is something like `?1.T` where `?1` is a skolem variable
of type `C[? >: L2 <: H2]`. OK, but what is the underlying (widened) type of `?1.T`?
We used to say it's `C[T >: L1 <: H1]`. I.e. we forgot about the actual arguments.
But then we had to change untupling desugarings from defs to vals in scala#14816 to fix
scala#14783 and it turned out that was not good enough, we needed the information of the
actual arguments, i.e. the type should be `C[T >: L2 <: H2]. Then something else started
failing which relied on the formal arguiment bounds being preserved. So the new resolution
was that the type would be the intersection of the formal parameter bounds and the actual
bounds, i.e. `C[T >: L1 | L2 <: H1 & H2]`. Then there was a series of problems where _that_
failed, either because the parameter bound was F-bounded or because the intersection was an
empty type. The latest installment is that the parameter bounds refer to another parameter
in the same class, which requires a simultaneous substitution of all skolemized bounds for
all dependent parameter references in the parameter bounds. But that's impossible or at least
very hard to achieve since we are looking at the type of a single parameter after capture conversion here.
So the current solution is to also back out of the intersection if there are cross-parameter
references and to use just the argument bounds instead.
jchyb
approved these changes
Sep 27, 2022
jchyb
added
the
backport:nominated
Kordyjan
added
backport:accepted
Kordyjan
added
backport:done
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Be still more careful when intersecting info and arguments of a class type parameter. This is the latest installment of a never-ending story.
The problem is this: Given
what is the type of
f().x?With capture conversion (an extremely tricky aspect of the type system forced on us since Java does it), the type is something like
?1.Twhere?1is a skolem variable of typeC[? >: L2 <: H2]. OK, but what is the underlying (widened) type of?1.T?We used to say it's
C[T >: L1 <: H1]. I.e. we forgot about the actual arguments. But then we had to change untupling desugarings from defs to vals in #14816 to fix #14783 and it turned out that was not good enough, we needed the information of the actual arguments, i.e. the type should beC[T >: L2 <: H2]. Then something else started failing which relied on the formal arguiment bounds being preserved. So the new resolution was that the type would be the intersection of the formal parameter bounds and the actual bounds, i.e.C[T >: L1 | L2 <: H1 & H2]. Then there was a series of problems where that failed, either because the parameter bound was F-bounded or because the intersection was an empty type. The latest installment is that the parameter bounds refer to another parameter in the same class, which requires a simultaneous substitution of all skolemized bounds for all dependent parameter references in the parameter bounds. But that's impossible or at least very hard to achieve since we are looking at the type of a single parameter after capture conversion here. So the current solution is to also back out of the intersection if there are cross-parameter references and to use just the argument bounds instead.