Unexpected tree in genLoad: TypeTree[TypeRef(ThisType(TypeRef(NoPrefix,module class inspector)),trait Tasty)]/class dotty.tools.dotc.ast.Trees$TypeTree #14783
Assignees
Labels
area:extension-methods
area:tasty-inspector
issues relating to the TASTy inspector
area:typer
itype:bug
itype:crash
Milestone
Comments
xuwei-k
added
itype:bug
itype:crash
stat:needs triage
Notecompiler does not throw error if add explicit type here tastys.zipWithIndex.foreach { (tasty, index) =>
- val tree = tasty.ast
+ val tree: q.reflect.Tree = tasty.ast
traverser.traverseTree(tree)(tree.symbol) |
Kordyjan
added
area:tasty-inspector
|
Self contained version object WartInspector:
def myWartTraverser: WartTraverser = ???
def inspect(using q: Quotes)(tastys: List[Tasty[q.type]]): Unit = {
val universe: WartUniverse.Aux[q.type] = WartUniverse(q)
val traverser = myWartTraverser.get(universe)
tastys.zipWithIndex.foreach { (tasty, index) =>
val tree = tasty.ast
traverser.traverseTree(tree)(tree.symbol)
}
}
object WartUniverse:
type Aux[X <: Quotes] = WartUniverse { type Q = X }
def apply[Q <: Quotes](quotes: Q): Aux[Q] = ???
abstract class WartUniverse:
type Q <: Quotes
val quotes: Q
abstract class Traverser extends quotes.reflect.TreeTraverser
abstract class WartTraverser:
def get(u: WartUniverse): u.Traverser
trait Tasty[Q <: Quotes & Singleton]:
val quotes: Q
def path: String
def ast: quotes.reflect.Tree
trait Quotes:
object reflect:
type Tree
extension (self: Tree) def symbol: Symbol = ???
type Symbol
trait TreeTraverser:
def traverseTree(tree: Tree)(symbol: Symbol): Unit |
|
Minimized to object Wart:
def bar(using c: Ctx)(ws: List[Wrap[c.type]]): Unit =
ws.zipWithIndex.foreach { (w, _) => w.x.foo }
trait Wrap[C <: Ctx & Singleton]:
val ctx: C
def x: ctx.inner.X
trait Ctx:
object inner:
type X
extension (self: X) def foo: Int = ??? |
|
With |
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Mar 31, 2022
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.
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Mar 31, 2022
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.
michelou
pushed a commit
to michelou/dotty
that referenced
this issue
Apr 25, 2022
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.
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Sep 27, 2022
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.
odersky
added a commit
that referenced
this issue
Sep 27, 2022
…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.
mpollmeier
pushed a commit
to mpollmeier/dotty
that referenced
this issue
Oct 16, 2022
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.
Kordyjan
pushed a commit
to dotty-staging/dotty
that referenced
this issue
Oct 17, 2022
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Compiler version
Minimized code
Output (click arrow to expand)
The text was updated successfully, but these errors were encountered: