Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Be still more careful when computing denotations of class parameters (#…
…16112) 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 #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 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.
- Loading branch information