bug

bug copied to clipboard

Reproduction steps

class Foo {
  def Bar: Double = 2.0
  def Baz: Double = 1.0
}

object Bar {
    def higherOrder2(f: Foo => Double, s: String): Nothing = ???
   higherOrder2(_.@@)
}

Problem

When trying to get completions after _. we don't get any results. I suspect it's because we are missing all the arguments. This works for one argument function.

I think there was a similar issue in Scala 3, but it could have been fix by Martin in https://github.com/lampepfl/dotty/pull/14695/files

Maybe it would be possible to backport those fixes to Scala 2 ? I think those parts haven't changed much. I will not have time to work on that unfortunately, but I was hoping this could be a quick look from someone more knowledgable about the compiler

I think a related broken example is

object MultiArg {
    def multiArg(f: (Double, Double) => Double): Nothing = ???
    multiArg(_.@@)
}

Here also, we get no completions after _..

Thanks both of you, I hope I'll find some time soon to take a look.

In the first example

class C { def fun = 0 }
def h(f: C => Int, s: String) = 0
h(x => x.f@@)

The parser will create an AST f(x => x.f) and attempt to type check it. This fails with a not enough arguments error when type checking, which initally leaves the argument x => ... untyped.

The argument is then type checked in the error handler but without an expected type (https://github.com/scala/scala/blob/v2.13.12/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L5064). In type-checking x => x.f without expected type we have no information about the type of x, so completions cannot find any results for x.f@@.

Maybe we can do some more best effor error recovery in interactive mode. So far I couldn't spot a flag or something to know if we're in an interacitve.Global or not.

The second example might be slightly different, haven't checked yet.

Thanks for looking into this!

Maybe we can do some more best effor error recovery in interactive mode. So far I couldn't spot a flag or something to know if we're in an interacitve.Global or not.

I think we would need to add one, though for Scala 3 I don't think it is used. The tree doesn't matter much if an error is reported anyway, so the whole compilation still fails.

I think we would need to add one, though for Scala 3 I don't think it is used. The tree doesn't matter much if an error is reported anyway, so the whole compilation still fails.

Yes, but I believe there are some cases where type checking method arguments with an expected type fails, but then typing them without succeeds and compilation continues. So we're not necessarily in an error state yet.