$conforms[Nothing] shows up as a placeholder for missing implicits

[julienrf]

minimized code

class Foo

List(new Foo).sorted

https://scastie.scala-lang.org/27qWTarCSHyAW7OtgXGGvg

The error message unexpectedly mentions $conform[Nothing].

No implicit Ordering defined for B

where:    B is a type variable with constraint >: Foo

I found:

    scala.math.Ordering.ordered[A]($conforms[Nothing])

But method $conforms in object Predef does not match type scala.math.Ordering.AsComparable[A].

expectation

The error message should be:

No implicit Ordering defined for B

where: B is a type variable with constraint >: Foo

(there should be no “I found: ...” part)

[julienrf]

I’ve tried to work on this issue today but I’m not sure where this is going…

$conforms[Nothing] is inferred everywhere we look for a given A => B. I’ve noticed that here we check whether a given candidate is compatible with the expected type. And in our case the $conforms candidate has type A => A, which is not compatible with A => B but still the NoViewsAllowed.isCompatible method returns true… I’m not sure if the type comparison function is wrong or if it’s the way we call it that returns the wrong answer. Any hint?

[julienrf]

As far as I understood, when we filter the given candidates, the comparison function does not take type parameter constraints into account. This is why a term with type [A] =>> A => A is considered to be a candidate for any function type.

You can reproduce the problem described in the first comment with this code:

summon[Int => String]

Gives the following error:

No implicit view available from Int => String.
I found:

    $conforms[Nothing]

But method $conforms in object Predef does not match type Int => String.

Since $conforms[Nothing] is uninhabited I think it would make sense to not show it to end-users. Unfortunately, in practice, it shows up a lot: any failing implicit search involving an Ordering instance might select $conforms[Nothing] because of this candidate, which is conditioned by a function. I’m not sure if there are other occurrences of this problem where we “find” a given candidate that turns out to not type check, but I believe it would be better to not keep those candidates in the first place when we filter them.

However, I’m not sure how to achieve this: if we try to fully type-check the given candidates when we filter them, this will surely slow down the compilation a lot…

What do you think of filtering the given candidates in two steps? First, the same step as the current filtering step, and then a second step which would try to type-chek only those that have passed the first step?