Skip to content

Fix -Ytest-pickler with super trees #5516

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.

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

Merged
merged 1 commit into from
Oct 15, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions compiler/src/dotty/tools/dotc/core/tasty/TreePickler.scala
Original file line number Diff line number Diff line change
Expand Up @@ -451,6 +451,7 @@ class TreePickler(pickler: TastyPickler) {
withLength {
pickleTree(qual);
if (!mix.isEmpty) {
// mixinType being a TypeRef when mix is non-empty is enforced by TreeChecker#checkSuper
val SuperType(_, mixinType: TypeRef) = tree.tpe: @unchecked
pickleTree(mix.withType(mixinType))
}
Expand Down
17 changes: 17 additions & 0 deletions compiler/src/dotty/tools/dotc/transform/TreeChecker.scala
Original file line number Diff line number Diff line change
Expand Up @@ -305,9 +305,26 @@ class TreeChecker extends Phase with SymTransformer {
override def excludeFromDoubleDeclCheck(sym: Symbol)(using Context): Boolean =
sym.isEffectivelyErased && sym.is(Private) && !sym.initial.is(Private)

/** Check that all invariants related to Super and SuperType are met */
def checkSuper(tree: Tree)(implicit ctx: Context): Unit = tree match
case Super(qual, mix) =>
tree.tpe match
case tp @ SuperType(thistpe, supertpe) =>
if (!mix.isEmpty)
assert(supertpe.isInstanceOf[TypeRef],
s"Precondition of pickling violated: the supertpe in $tp is not a TypeRef even though $tree has a non-empty mix")
case tp =>
assert(false, s"The type of a Super tree must be a SuperType, but $tree has type $tp")
case _ =>
tree.tpe match
case tp: SuperType =>
assert(false, s"The type of a non-Super tree must not be a SuperType, but $tree has type $tp")
case _ =>

override def typed(tree: untpd.Tree, pt: Type = WildcardType)(using Context): Tree = {
val tpdTree = super.typed(tree, pt)
Typer.assertPositioned(tree)
checkSuper(tpdTree)
if (ctx.erasedTypes)
// Can't be checked in earlier phases since `checkValue` is only run in
// Erasure (because running it in Typer would force too much)
Expand Down
2 changes: 1 addition & 1 deletion compiler/src/dotty/tools/dotc/typer/TypeAssigner.scala
Original file line number Diff line number Diff line change
Expand Up @@ -255,7 +255,7 @@ trait TypeAssigner {
errorType("ambiguous parent class qualifier", pos)
}
val owntype =
if (mixinClass.exists) mixinClass.appliedRef
if (mixinClass.exists) mixinClass.typeRef
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think neither old nor new version is right. What about this scenario?

trait A[X]
class B extends A[Int] {
  super[A] // should have type A[Int], not A, or A[X]
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's a bit weird, but if we change this then we need to change the pickling/unpickling scheme for super which currently does:

            case SUPER =>
              val qual = readTerm()
              val (mixId, mixTpe) = ifBefore(end)(readQualId(), (untpd.EmptyTypeIdent, NoType))
tpd.Super(qual, mixId, ctx.mode.is(Mode.InSuperCall), mixTpe.typeSymbol

So won't work with mix being an AppliedType.

Alternatively we could change SuperType#underyling to work like SuperType#superType, currently they're different:

  abstract case class SuperType(thistpe: Type, supertpe: Type) extends CachedProxyType with SingletonType {
    override def underlying(implicit ctx: Context): Type = supertpe
    override def superType(implicit ctx: Context): Type =
thistpe.baseType(supertpe.typeSymbol)

But note that in practice I haven't found a case where the current definition breaks something, e.g. in findMember we call underlying on SuperType but that ends up working out since findMember keeps around the prefix of the call as pre which contains all the information we need to figure out the type parameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe underlying in supertype is fine.

I don't see right now why pickler/unpickler has to change. Should we not instead change the TypeAssigner to do the same as SuperType$superType?

Copy link
Member Author

@smarter smarter Mar 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coming back to this PR 2 years (!) later, I believe I'm still confused by why underlying and superType are different in SuperType, if I follow your advice of making TypeAssigner use the same logic as superType to set superTpe, then they would always be the same anyway. Would you mind taking another look at this?

Copy link
Contributor

@odersky odersky Oct 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have deep insights here either. underlying does not do baseType invocations, and superType should probably do that.

That said, I now think the change in TypeAssigner makes sense. If everything passes with that change, let's do it.

else if (!mix.isEmpty) findMixinSuper(cls.info)
else if (ctx.erasedTypes) cls.info.firstParent.typeConstructor
else {
Expand Down
1 change: 0 additions & 1 deletion compiler/test/dotc/pos-test-pickling.blacklist
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,6 @@ i94-nada.scala
i1812.scala
i1867.scala
i3067.scala
t247.scala
t2712-5.scala
t284-pos.scala
t3249
Expand Down