Reduce projections of type aliases with class type prefixes

[odersky]

Projections P # X are types that we would like to avoid. If X is a class type, there's nothing we can do. If X is an abstract type, we use skolemization and rewrite to (x?: P).X. If X is an alias type we should simply dealias but this was not done before.

This caused an exponential blowup in #19892, where we constructed types of the form

ZPartialServerEndpoint[R, A, B, I, E, O, -C] # EndpointType[A, I, E, T, R] ... # EndpointType[A, I, E, T, R]

When the were 5 or more such selections, compile times blew up (33s for 5, timeout after 5 minutes for 6). I am still not quite sure where the blowup happened. Looking at stacktraces of random interrupts it seemed to be in a deep recursion of memberDenot and asSeenFrom calls.I believe it would still be interesting to find out more about this, in case there are other similar situations where combinations of deep projections with wide applications cannot be avoided.

But for this precise problem, eagerly dealiasing fixes it.

Fixes #19892

[odersky]

@rochala Can you help me fix the 2 presentation compiler test failures? I am not sure what to do here.

[rochala]

I'll check it the first thing in the morning

[rochala]

Dealiasing affects the typed trees which we are using for various features.
The tests that failed can be fixed by migrating to untyped trees, but there are other features such as hovers / go to type definition which can be more problematic, as the types are already dealiased.

I suppose it could be done if we analyse each select whether it is actually a type projection, and try recreating the original type by hand.

I will try to implement those workarounds unless you have a better idea.

[odersky]

Does it just apply to # projections A # X? In that case I think we can also simply drop the behavior and the tests. Such projections are quite rare. For instance the dotty code base does not have a single occurrence of #. So I personally would not care at all what kind of hovers I get. And for others it would be a good indicator to change the design, since IME relying on # usually does not end well.

I believe the only reason to use A # B is if both A and B are classes and we want to model references to inner classes in the Java style. Otherwise, if you have to resort to it, it usually means your design is wrong. Maybe we should do a linter rule for that.

[rochala]

Does it just apply to # projections A # X?
It seems like this is the case.

This functionality was only tested in one suite, the one that failed, so I can say it wasn't truly supported by presentation compiler. This also impacts generated semanticdb output.

Feel free to add @Ignore for those tests. I'll create the ticket for this after this PR is merged so we don't lose a track of this.
Other than that, I think the review of the solution should be done by someone more experienced.

[odersky]

test performance please

[odersky]

We should get benchmarks back before we can merge this. I want to rule out slowdowns in some scenarios.

[mbovel]

test performance please

[dottybot]

performance test scheduled: 149 job(s) in queue, 0 running.

[dottybot]

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/19931/ to see the changes.

Benchmarks is based on merging with main (a36849f)

[odersky]

So performance seems to not worse and maybe a bit better. @smarter do you want to give this q quick review?

[smarter]

Otherwise LGTM.

[smarter]

We can also create projections where the prefix is a type alias (they're not always reduced, e.g. when the alias has a different number of type parameters than the aliasee), which can trigger the performance cliff again:

abstract class ZPartialServerEndpoint[R, A, B, I, E, O, -C]
    extends EndpointOps[A, I, E, O, C]{
  override type ThisType[-_R] = ZPartialServerEndpoint[R, A, B, I, E, O, _R]
  override type EndpointType[_A, _I, _E, _O, -_R] =ZPartialServerEndpoint[R, _A, B, _I, _E, _O, _R]
}

trait EndpointOps[A, I, E, O, -R] {
  type EndpointType[_A, _I, _E, _O, -_R]
  type ThisType[-_R]
  def out[T]: EndpointType[A, I, E, T, R]
  def description(d: String): ThisType[R]
}

object Test {
  type Alias[R, A, B, I, E, O] = ZPartialServerEndpoint[R, A, B, I, E, O, Any]
  def basicEndpoint[R](): Alias[R, Any, Any, Unit, Any, Unit] = ???

  // commonts next to `.out[Any]` contain information about compilation time when chaining up to N `out` functions
  val case1 =
     basicEndpoint() // 1.5s
        .out[Any] // 1.6s
        .out[Any] // 1.7s
        .out[Any] // 2s
        .out[Any] // 4s
        .out[Any] // 33s
        .out[Any] // aborted after 5 min
}

[odersky]

Yes, but I am not sure we can dealias without breaking stuff here. It is a super low-level code.