-Yretain-trees (and flags which imply it like -Ysafe-init) changes the types of trees returned by the reflection API

[cchantep]

Compiler version

3.1.2-RC1-bin-20211222-c94b333-NIGHTLY

Minimized code

🤚 With -Ysafe-init in scalacOptions

import scala.deriving.Mirror
import scala.quoted.*
import scala.reflect.ClassTag

inline def test[A]: Unit = ${ testImpl[A] }

private def testImpl[A](
  using
    q: Quotes,
  t: Type[A]
): Expr[Unit] = {
  import q.reflect.*

  val tpr = TypeRepr.of[A]

  tpr.classSymbol.foreach {
    _.tree match {
      case cd: ClassDef =>
        val tpe = cd.constructor.returnTpt.tpe

        println(s"classTpe = ${tpe.show}")

      case _ =>
    }
  }

  '{ () }
}

// Execute test below:

final class Foo(val name: String)

test[Foo]

Output

classTpe = scala.Unit

Expectation

classTpe = Foo

⚠️ Expected result ok without -Ysafe-init

[liufengyun]

The usage of the compiler flag -Yretain-trees has the same behavior as -Ysafe-init above.

Note that the usage of sym.tree is discouraged in meta-programming, as specified in the document here: https://scala-lang.org/api/3.x/scala/quoted/Quotes$reflectModule$SymbolMethods.html#tree-d26

The following code is a better way to achieve the goal without using sym.tree:

  tpr.classSymbol.foreach { sym =>
    tpr.memberType(sym.primaryConstructor) match {
      case MethodType(_, _, resTp) =>
        println(s"classTpe = ${resTp.show}")

      case _ =>
    }
  }

[cchantep]

There are some (many) cases where you need to go through the tree, so the issue remains.

[smarter]

If you need to go through the tree this is likely due to something missing in the reflection API and should be reported as a bug, but regardless we should ensure that the behavior of tree.tpe does not change based on whether -Yretain-trees is enabled or not

[cchantep]

If you need to go through the tree this is likely due to something missing in the reflection API and should be reported as a bug,

e.g. There is no way to find the known subtypes from a TypeRepr, whereas the .children is available on Symbol (so aTypeRepr.symbol.children), but then there is no clean way to resolve a TypeRepr for each of the children, except pattern matching of Symbol.tree.

but regardless we should ensure that the behavior of tree.tpe does not change based on whether -Yretain-trees is enabled or not

Yes

[smarter]

there is no clean way to resolve a TypeRepr for each of the children

I believe this is tracked by #13553

[cchantep]

there is no clean way to resolve a TypeRepr for each of the children

I believe this is tracked by #13553

No, #13553 is about resolving the TypeRepr for a Symbol, no resolving sub-types for a type using its TypeRepr (with something like TypeRepr.children).

[smarter]

I expect you would do tp.symbol.children.map(_.info) to get back the types.