Fix parameter untupling #14816

odersky · 2022-03-31T10:09:20Z

As a preliminary: #14783 shows an example where an implicit reference was generated that started in a type.
The backend then crashed since it could not emit instructions to load that reference. We
now detect such references when they are created and flag them as errors.

The main commit is to fix the issue that created the bad reference in the first place.
Make untupled parameters ValDefs instead of DefDefs so that their references are
stable paths. Add an additional check that untupled parameters don't come from
call-by-name parameters (in that case, ValDefs would be unsound).

I was trying hard to allow paramater untupling for cbn parameters, but this seems to be
very hard since parameter untupling happens as a desugaring step when the expected
parameter type is not yet known. And it seems really hard to change from stable to
unstable (or vice versa) later in the compilation pipleline without doing a lot of
re-checking.

Since untupled cbn parameters are a pretty extreme corner case anyway I think it's
OK to just disallow them.

Fixes #14783

scala#14783 shows an example where an implicit reference was generated that started in a type. The backend then crashed since it could not emit instructions to load that reference. We now detect such references when they are created and flag them as errors. We need to separately fix the issue that created the bad reference in the first place.

Make untupled parameters ValDefs instead of DefDefs so that their references are stable paths. Add an additional check that untupled parameters don't come from call-by-name parameters (in that case, ValDefs would be unsound). I was trying hard to allow paramater untupling for cbn parameters, but this seems to be very hard since parameter untupling happens as a desugaring step when the expected parameter type is not yet known. And it seems really hard to change from stable to unstable (or vice versa) later in the compilation pipleline without doing a lot of re-checking. Since untupled cbn parameters are a pretty extreme corner case anyway I think it's OK to just disallow them.

We sometimes create a dependent parameter reference p.X where `p` is a path with a type that has a wildcard argument, e.g. `P[X >: L <: H].` So far the denotation of `p.X` had as info the bounds with which `X` was declared in `P`. Now it gets the actual parameter bounds instead. Fixes scala#15652 scala#15652 started failing when tuple unpackings started to use `val`s instead of `def`s in scala#14816. That caused dependent class parameter references to be created and uncovered the problem.

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.

…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.

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.

We sometimes create a dependent parameter reference p.X where `p` is a path with a type that has a wildcard argument, e.g. `P[X >: L <: H].` So far the denotation of `p.X` had as info the bounds with which `X` was declared in `P`. Now it gets the actual parameter bounds instead. Fixes scala#15652 scala#15652 started failing when tuple unpackings started to use `val`s instead of `def`s in scala#14816. That caused dependent class parameter references to be created and uncovered the problem.

odersky force-pushed the fix-14783 branch from 6f0f8df to 8627429 Compare March 31, 2022 13:02

Don't require loadable when trying extension methods

20cc92e

odersky force-pushed the fix-14783 branch from 8627429 to 20cc92e Compare March 31, 2022 14:23

odersky changed the title ~~Flag unloadable references as errors~~ Fix parameter untupling Mar 31, 2022

odersky force-pushed the fix-14783 branch from a8ade92 to 0a95a3d Compare March 31, 2022 17:15

odersky requested a review from nicolasstucki March 31, 2022 19:14

odersky assigned nicolasstucki Mar 31, 2022

odersky merged commit d673b97 into scala:main Apr 8, 2022

odersky deleted the fix-14783 branch April 8, 2022 11:50

griggt mentioned this pull request Jul 12, 2022

Possible regression in type inference #15652

Closed

odersky mentioned this pull request Jul 13, 2022

Better infos for dependent class parameter references #15667

Merged

odersky mentioned this pull request Sep 27, 2022

Be still more careful when computing denotations of class parameters #16112

Merged

Kordyjan added this to the 3.2.0 milestone Aug 1, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix parameter untupling #14816

Fix parameter untupling #14816

odersky commented Mar 31, 2022 •

edited

Loading

Fix parameter untupling #14816

Fix parameter untupling #14816

Conversation

odersky commented Mar 31, 2022 • edited Loading

odersky commented Mar 31, 2022 •

edited

Loading