Add reflect TypeLambda.paramVariances

[nicolasstucki]

Fixes #16734

[nicolasstucki]

@neko-kai could you check if the test example is representative of your use cases?

[neko-kai]

@nicolasstucki
Almost, there's the type lambda case

variances[[A] =>> K1Cov[A]]

I think that's the case that broke in 3.3.0 - before that declaredVariances returned +A for this type lambda, now it doesn't - so we'd need a function that tells the real computed variance of a A inside this type lambda - even if type lambda itself is not variance-annotated. Thank you for helping us here btw!

[neko-kai]

@nicolasstucki
There's also the type param case

variances[[A, F[+_]] =>> F[A]]

[bishabosha]

// from the test case
variances[[A, F[+B]] =>> F[A]]

currently the result for A is that it is still "declared" invariant, which is true, but would it be also possible to expose how the compiler computes the real variance of A? (which is what #16734 is asking for) or should macro authors compute that themselves?

[nicolasstucki]

@neko-kai to make these work, I used paramVariance instead of declaredVariances. Is this the functionality you need? See the variances in the check file. If it is what you need then you could also access this method reflectively as a workaround in 3.3.0.

[neko-kai]

@nicolasstucki
Yes, thank you! That's what I'll do right now, but it'd be great to have a public API anyway, to stop using reflection for this in the future.

[nicolasstucki]

Currently the result for A is that it is still "declared" invariant, which is true, but would it be also possible to expose how the compiler computes the real variance of A? (which is what #16734 is asking for) or should macro authors compute that themselves?

I changed that when I switched to paramVariances. Now we return the computed variances.

[smarter]

Having this just on TypeLambda is a bit limiting since classes also have parameter with variance annotations, it would be nice if the same API worked for TypeLambda, TypeRef of classes and TypeRef of parameterized type aliases.

[nicolasstucki]

I added Symbol.paramVariance and added tests for all these cases. I did not add it on TypeRef because it is more consistent if we go to the definition of the class and ask for the variances on it.

[smarter]

Could we simply assert that this is a type parameter to prevent misinterpreting EmptyFlags as Invariant on things which aren't type parameters?

[nicolasstucki]

We do not show the distinction between type and term flags in the reflection API.

[bishabosha]

needs a rebase