Fix #8215 Add ability to detect attempted Tasty inspection of a Java class

[gzoller]

Linking #8215

When initiating Tasty Inspection from a class, in some situations it may not be known whether the class is a Java or Scala/Tasty class, and the caller may want to handle the Java classes differently. (Of course an attempt to Tasty Inspect a non-Tasty class will result in an empty root Tree in TastyInspector.)

Unfortunately Java itself offers no way to detect host language in their Class API, but I noticed that ReadTasty fails in a consistent way with Java classes, and that it's possible to read the symbol Flags and detect JavaDefined at that point.

Wanting to minimize changes, I created a JavaCompilationUnit marker so that ReadTasty could proceed as normal upon hitting a Java class, and bubble this result up the call stack. Then I modified the Reflection.Context API to add a method that returns an Option[String] for Java class name (Some(the name) if Java, None if Tasty).

Now within TastyInspector I can simply do:

  protected def processCompilationUnit(reflect: Reflection)(root: reflect.Tree): Unit = 
    import reflect.{given,_}
    reflect.rootContext.getJavaClassname()
      .map( javaClass => doSomethingHereWithJava(javaClass) )
      .orElse(doSomethingHereWithTasty(...))

Anyone not caring about Java classes will have see no change in Dotty's behavior.

[dottybot]

Hello, and thank you for opening this PR! 🎉

All contributors have signed the CLA, thank you! ❤️

Have an awesome day! ☀️

[gzoller]

Seeking advice here... I'm getting a build failure but to the best of my knowledge it doesn't seem related to my change. What's the best way to proceed? Worst case I could re-clone the latest master branch and re-apply my changes?

[gzoller]

Ok, after a lot of re-testing, I've learned some things. There is something my change, specifically the change in ReadTasty.scala that breaks the 'from-tasty' test. It shouldn't--but it does. Need to keep digging to see why.

[gzoller]

Narrowing down the problems. In ReadTasty.scala I'm trying to detect the presence of an attempted read of a Java file by looking at the flags of the symbol available at this point:

      def compilationUnit(cls: Symbol): Option[CompilationUnit] = cls match {
        case cls: ClassSymbol =>
          (cls.rootTreeOrProvider: @unchecked) match {
            case unpickler: tasty.DottyUnpickler =>
               //... some code...
            case tree: Tree[?] =>
              println("   Flags: "+cls.flags)
              alreadyLoaded()
            case _ =>
              cannotUnpickle(s"its class file does not have a TASTY attribute")
          }

Here's where the fun starts. I can try calling ReadTasty in 2 cases: 1) passing in a Java file and 2) passing in a Scala file w/o a .tasty file, scala.collection.immutable.RedBlackTree in the case of the test code.

Here's what's weird... In both cases cls, the ClassSymbol, is the same kind of thing: dotty.tools.dotc.core.Symbols$ClassSymbol. But... in the case of a Java file there are flags available, and calling cls.flags works fine and I can test for JavaDefined (true). In the case of a non-Tasty Scala class though, just trying to access cls.flags blows up as a java.lang.UnsupportedOperationException! Didn't expect that. Going to have to dig deeper...

[gzoller]

Yay--bug found and fixed! Reviews and comments invited.

[nicolasstucki]

Thank you @gzoller