Make suggestions of missing implicits imports on type errors

[odersky]

Add an addendum to an error message where the error might be fixed
by some implicit argument or conversion or some extension method
that is however not found. The addendum suggests implicit
imports that might fix the problem.

[He-Pin]

Finally see some Unison style error msg:)

[julienrf]

I’m extremely happy to see work in this direction! ❤️

I believe we should also provide suggestions for dynamic givens: given members that can be provided by extending or instantiating a class, as opposed to importing a static value. This could be done in a separate PR, though. Should I open an issue to keep track of such a feature?

[julienrf]

This signature looks error-prone to me as there is no way to distinguish between the presence and the absence of a suggestion (in any case, a String is returned). What do you think of returning an Option[String] instead? Returning an empty String to model the absence of suggestion does work here by chance because this method is the latest to be called in a chain of if/else if, but we should not have to look at how this method is called to be able to reason on its correctness (this is not the concern of this method, we should be able to locally reason about it).

[odersky]

In fact an empty string is preferable, since it's easier to consume. Generally, the compiler always prefers sentinels over optional values, as long as feasible.

[odersky]

I believe we should also provide suggestions for dynamic givens: given members that can be provided by extending or instantiating a class, as opposed to importing a static value. This could be done in a separate PR, though. Should I open an issue to keep track of such a feature?

It would be good to see some examples of this, and brainstorm about possible scenarios how to do this.

[julienrf]

Thanks for adding the test!

May I ask to also add the following tests?

trait X
trait Y
def f(given x: X) = ???
object instances {
  given y: Y = ???
}
locally {
  given xFromY(given y: Y): X = ???
  f // error
}
locally {
  object instances2 {
    given xFromY(given y: Y): X = ???
  }
  f // error
}

trait X[A, B]
trait Y
trait Z
given xyz: X[Y, Z] = ???
object instance {
  given z: Z = ???
}
def f[A](given xya: X[Y, A], a: A) = ???
f // error

trait X

object instance1 {
  given x: X = ???
}
object instance2 {
  given x: X = ???
}

implicitly[X] // error

I believe we should also provide suggestions for dynamic givens: given members that can be provided by extending or instantiating a class, as opposed to importing a static value.

It would be good to see some examples of this, and brainstorm about possible scenarios how to do this.

Here are some examples:

• In Akka Streams, an implicit ActorSystem instance has to be provided by the user, the Dotty staging API requires a given Toolbox to be provided by the user, the Dotty compiler uses an implicit Context that has no static instance,
• FailFastCirceSupport from akka-http-json, Custom bundles from scalatags, Directives classes from Akka HTTP, Instance or Syntax classes from Cats.

So, there seem to be two cases: either the class is the very type that the compiler is looking for (ActorSystem, Toolbox, etc.), or the class provides implicit members that the compiler is looking for (FailFastCirceSupport, etc.).

Maybe the first case is relatively easy to manage without suggestions from the compiler? If a user already knows how to instantiate that class, then he only has to make that instance a given instance, which should be easy to figure out just by getting the “no implicit argument of type T …” message.

For the second case, it is worth noting that it is a common practice for library authors to also provide a static object that extends the class providing the given members (for instance, akka-http-json also provides an object FailFastCirceSupport extends FailFastCirceSupport), which means that that object should already be mentioned in the suggestions.

So, maybe suggesting static imports is enough, after all!

[julienrf]

This part of the error message is confusing. It should not say that traverse is not a member, but that no argument of type Zip[Option] was inferred.

[odersky]

I improved the first line, it now says:

16 |  List(1, 2, 3).traverse(x => Option(x)) // error
   |  ^^^^^^^^^^^^^^^^^^^^^^
   |  value traverse is not a member of List[Int], but could be made available as an extension method.
   |
   |  The following import might make progress towards fixing the problem:
   |
   |    import testObjectInstance.instances.traverseList

[julienrf]

I believe that eventually, we should not provide suggestions for implicit conversions (but this is currently necessary to support the implicit classes of the scala-library 2.13), only for given instances of type Conversion.

[soronpo]

Maybe a dumb question, because I don't know enough about LSP and editors, but is it possible to have this information available as a service by the front-end compiler aside from an error message, to make it easier for the editors to internally use hints instead of parsing the error messages?

[odersky]

@soronpo I don't know enough about LSP to answer this question.

[gabro]

@odersky the LSP idiom I would use here is a Code Action: code actions can be used to provide fixes for existing errors (in which case they’re called “quickfixes” in LSP lingo) and this seems to be a perfect match.

I don’t know the status of dotty’s own LSP implementation but Metals already provides a similar action (import missing symbol) and it would make sense to implement this there, once we support Scala 3.

Is it possibile to surface this “hint” API to the presentation compiler so that external tools such as Metals can use it?