Fix #6238 (take 3): Strip WildcardType when applying arguments

[smarter]

Here's my alternative to #6240 inspired by the other alternative: #6250 :). There's a single test failure which I haven't figured out:

> run tests/pos/typeclass-encoding3.scala
-- Error: tests/pos/typeclass-encoding3.scala:284:25 ---------------------------
284 |    ev.inject(Monad.by[F].pure(x)).map(f)
    |                         ^
    |no implicit argument of type Test.Monad.Common{This = F} was found for parameter ev of method by in object Monad
-- Error: tests/pos/typeclass-encoding3.scala:288:30 ---------------------------
288 |    f => ev.inject(Monad.by[F].pure(x)).flatMap(f)
    |                              ^
    |no implicit argument of type Test.Monad.Common{This = F} was found for parameter ev of method by in object Monad

@odersky Could you take a look and see if the change to wildApprox makes any sense ?

[odersky]

I am still not sure what goes on here. Both fixes disable wildcarding in some instances (or, rather, this one reverses it). But (a) I am not sure why this helps and (b) this is dangerous. We risk getting a cache miss and with it failing to find an implicit. I think we need to come up with a complete explanation what goes wrong and why the fix is both complete and safe before proceeding.

[milessabin]

@odersky my intuition was that it's incorrect to approximate type parameter refs of type parameters bound in the type itself. My understanding is that the point of approximating with wildcards (in Implicits.scala at least) is to avoid adding bogus constraints to type vars bound outside the type being approximated.

I restricted my fix to HKTypeLamdas simply to make the most conservative change possible to fix clearly broken cases wrt kinding, but I can believe that the problem might be more general.

[odersky]

my intuition was that it's incorrect to approximate type parameter refs of type parameters bound in the type itself.

That looks reasonable. So maybe do just that? We can keep bound type parameters in a set in wildApprox and keep them unchanged if we see them.

Given the subtlety of wildApprox it's important to find a solution that clarifies things and whose correctness is evident.

[milessabin]

@odersky

So maybe do just that?

That's pretty much what I did. The complication is that the internally bound type params might have bounds which are bound externally, and those do need to be wildcarded. I think that accounts for most of the additional complexity that you're seeing in #6240.

And again, I restricted this to just HKTypeLambdas as the conservative option. If you'd prefer that I cover all the similar binders as well I'd be happy to give that a try.

[milessabin]

@odersky @smarter more thoroughgoing attempt at "just doing that" here: #6271.

[smarter]

Closing in favor of the now-merged #6271