This PR re-opens #4757 with a fix for the last crash I mentioned that occurred when attempting to find the functional method. Please see the bottom of the PR description for a description of the issue and fix.

Original PR description

This PR improves lambda-related method resolution by using the lambda parameter count and body for disambiguation in two cases described below. I implemented this by adding the required information to the LambdaArgumentTypePlaceholder class, but made sure that, if this information is not provided (such as for MethodReferenceExpr, type resolution behaviour will be the same as before this PR.

Different parameter counts

import java.util.function.Consumer;

class Test {
    void foo(Consumer<String> consumer) {}
    void foo(Runnable r) {}

    void test() {
        foo(input -> {});
    }
}

Consumer.accept has one parameter while Runnable.run has zero, so since the lambda has one parameter, we know this must resolve to foo(Consumer<String>)

Disambiguation by return type

import java.util.function.Consumer;
import java.util.function.Function;

class Test {
    void foo(Consumer<String> consumer) {}
    void foo(Function<Integer, String> func) {}

    void test() {
        foo(input -> {});
    }
}

In this example, the body of the lambda is a block statement which does not contain any return statements. This means that the lambda can only define a method with a void return type, so it must define Consumer<String> (the same would be true for foo(input -> { return; }).

If it were foo(input -> { return ""; }) instead, then the reverse logic would apply. Since the return type of the lambda is not void, it cannot define Consumer and must therefore define Function.

New in this PR

This issue occurred when attempting to resolve a call to a method where one of the parameters is a functional interface that extends a different functional interface but overrides one of the generic types, for example:

import java.util.function.Function;
 
@FunctionalInterface
interface ReturnStringFunction<T> extends Function<T, String> {
  String apply(T t);
}

class Foo {
  static <T> String foo(T t) { return null; }
}

public class Test {
  <T> String acceptsFunction(ReturnStringFunction<T> consumer) { return null; }

  void test() {
    acceptsFunction(Foo::foo);
  }
}

In this example, the Foo::foo method reference has to be resolved to resolve the acceptsFunction call. 2 candidate methods for the method implemented by Foo::foo are found:

R apply(T t) from java.util.function.Function<T, R>

and

String apply(T t) from ReturnStringFunction<T>

At some point during the resolution, it must be determined whether these method return types are substitutable or not. The logic for doing this already exists, but method1.isReturnTypeSubstitutable(method2.returnType()) only handles the case where the return type of method2 is a type variable. If the return type of method1 is a type variable, then this crashes with an UnsupportedOperationException. I've added a fix where, if the return type of method1 is a type variable and all other checks have been done, false is returned since in general the concrete return type of method2 cannot be substituted for the type variable.