Mark AppliedType cachedSuper valid Nowhere when using provisional args

[EugeneFlesselle]

I'm not sure why it wasn't the case previously.

It solves some stale caching issues I encounter when introducing more caching for match types in #20268, as well as the problem in neg/typeclass-encoding3 apparently.

There seems to be no significant performance impact from the reduced opportunities for caching.

[EugeneFlesselle]

test performance please

[dottybot]

performance test scheduled: 50 job(s) in queue, 1 running.

[EugeneFlesselle]

test performance please: 59b0f3a c6fbe6f

[dottybot]

performance test scheduled for 59b0f3a c6fbe6f: 50 job(s) in queue, 1 running.

[dottybot]

Performance test finished successfully:

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

Benchmarks is based on merging with main (746b00b)

[EugeneFlesselle]

The last commit only changes a test case, the previous commit (with the change in AppliedType) looks to be inline with main.

[odersky]

I'm not sure why it wasn't the case previously.

I think the thinking was because it's only type constructor that influences the shape of the supertype, if the type constructor is no longer provisional, the supertype is always the same. It might still be provisional if one of the arguments is provisional, but that's another question. I am not really sure where the hole in that reasoning is. The change seems to fix something, but i am not sure why. It would be good to have an explanation, why the problem happened and how changing isProvisional fixed it.

[EugeneFlesselle]

After some investigation, here is what I found: TypeApplications#appliedTo can perform reductions that depend on the arguments, which are not structurally insignificant (although it is true the results are equal with respect to =:=).
In particular, it will perform eta-reduction if the de-aliased tycon is an HKTypeLambda and the dealiased.paramRefs == dealiasedArgs, but ignoring variance annotations.
This can have an impact on TypeComparer#compareTypeLambda as it requires the variances to conform.

In the example of pos/typeclass-encoding3b

object Monad extends TypeClassCompanion1:
  type Impl[T[_]] = MonadCommon { type This = [X] =>> T[X] }

implicit object ListMonad extends MonadCommon:
  type This[+X] = List[X]

def flattened[T[_], A]($this: T[T[A]])(implicit ev: Monad.Impl[T]): T[A] = ???
flattened(List(List(1, 2, 3), List(4, 5)))(using ListMonad)

the key observation is that the This type member of ListMonad has a variance annotation.

When checking ListMonad <:< functors.Monad.Impl[T] we eventually get to the comparison [X] =>> T[X] <:< [+X] =>> List[X] which fails the variance conformance checks, despite the fact that T has been instantiated to List, since it has been substituted into the refinement (and cached) before its instantiation.
If we however recompute the superType after having found T := List, appliedTo now yields the same covariance annotation, which allows the type comparison to succeed.

[EugeneFlesselle]

If the changes in this PR are deemed sufficient to address the issue, I can definitely add a comment to AppliedType#superType explaining why the change is needed.

[odersky]

That's a great answer. I think we should have a condensed version in the code for AppliedType#superType, with a link to the test that would otherwise fail.

The changes look all good to me.

[EugeneFlesselle]

That's a great answer. I think we should have a condensed version in the code for AppliedType#superType, with a link to the test that would otherwise fail.

Sounds good, I'll do that 👍

[EugeneFlesselle]

Note I also added a change unrelated to the doc in ee54814

[dwijnand]

LGTM, just a question

[dwijnand]

I don't follow the comment. How does it failing the conformance check lead it to not erroring?

[EugeneFlesselle]

Ah, I'd overlooked updating the tense