Support Java 17 sealed in Java sources

[som-snytt]

Support sealed in Java sources. The related PR supports separate compilation, where PermittedSubclasses attribute specifies sealedness; there seems to be no ticket for that, alas. This PR is Java interop gravy.

Fixes scala/bug#12171
Fixes scala/bug#12159

[SethTisue]

@lrytz tentatively milestoned for 2.13.11 since it address a concern you raised on #10105

[som-snytt]

The updated commit just "registers" Java classes and matches for completion after typer, where (per lrytz) either there is a permits or we look at classes from the same source file.

The simple impl could be improved or complexified further. Or simplified.

[lrytz]

Thanks, great to see that we can make it work!

Why do you think we should delay until after typer? Forcing is what the typer does, I don't see a particular risk of running into cycles here, we don't need to infer anything to complete these class symbols.

For finding symbols defined in a particular compilation unit, I also think we need new global state, there doesn't seem to be anything we can reuse. A question is where to put it, I guess it doesn't matter too much. Here's a draft, what do you think (last commit)? 2.13.x...lrytz:scala:pr10348

[som-snytt]

Yes, that is what I was thinking of (a perRunCaches Map). I thought keeping the logic in one place was simpler, "children we know about" and "other offspring". Oh I see what you mean, we've already seen all the classes for this unit, nothing is gained by waiting.

The other piece I started looking at was emitting the permittedSubclasses attribute for Scala sealed. I'll try to add a commit for that, I was about to imitate some structure for innerClasses.

A final clean-up is also to review the tests for duplication or completeness.

Also, this is a patmat feature, so I like that it looks that way by putting the unwieldy sources map there.

[som-snytt]

I added your commits and will push after cleaning up my detritus.

Also I haven't touched the java parser to look more like your earlier edit, which I remember preferring.

[som-snytt]

what happens to errors on bad permits clause here?

[lrytz]

We forgot about inner classes...

package p;
public sealed interface X {
  public default int x() { return 1; }
}
final class Y implements X { }
final class O {
  final static class Z implements X { }
}

package p
class T {
  def n(a: X) = a match { case _: Y => 0 }
}

Should warn but doesn't in mixed compilation. Namer eagerly greates symbols for top-level classes. But symbols for inner classes are only created when the outer class completes.

So if there's a sealed Java type without a permits clause, we probably have to recursively force all classes defined in the same compilation unit.

X.java:9: error: anonymous classes must not extend sealed classes
    X bar = new X() { };
                    ^

😅 OK, at least that

---

@retronym brought runtime reflection to the table:

scala> import scala.reflect.runtime.{universe => ru}
import scala.reflect.runtime.{universe=>ru}

scala> ru.typeTag[p.X].tpe.typeSymbol.asClass.knownDirectSubclasses
val res0: Set[reflect.runtime.universe.Symbol] = Set()

Also macros / compiler plugins might want to see children, not only the exhaustivity checker. But I think it's fine to defer that.

[som-snytt]

@lrytz this will be green after squashing. I guess "zucchini", as a green squash.

I'll take another look at the tweak to populating the sealed class hierarchy. It needs tests with non-sealed descendants.

[lrytz]

🥒 ed

LGTM, thank you!