Ensure HasAnonymousFunctionConversion returns without binding lambda body for explicitly-typed lambda

[sharwell]

Warning: The assumptions made in this post appear to be incorrect. See #69093 (comment).

81.1% of the CPU time spent on the IntelliSense thread in #67926 is calling HasAnonymousFunctionConversion.

This issue relates to the following code:

roslyn/src/Compilers/CSharp/Portable/Binder/Semantics/Conversions/ConversionsBase.cs

Lines 1059 to 1064 in ebc2841

	case BoundKind.UnboundLambda:
	if (HasAnonymousFunctionConversion(sourceExpression, destination))
	{
	return Conversion.AnonymousFunction;
	}
	break;

This code should return without binding the contents of the lambda if the lambda explicitly declares all types related to its signature. For example, the following lambda declares its parameter types and its return value explicitly, and therefore can be evaluated for having a conversion without further binding.

SomeInvocation(int (string arg) => { /* none of this matters */ });

While this guarantee doesn't automatically fix the problem described in #67926, it provides the user with a viable workaround in nested lambda cases where they can explicitly declare the types and avoid further costs.

[sharwell]

It looks like the error cases for return type and parameter types are handled here:

roslyn/src/Compilers/CSharp/Portable/Binder/Semantics/Conversions/ConversionsBase.cs

Lines 1434 to 1441 in 993fcc8

	if (anonymousFunction.HasExplicitReturnType(out var refKind, out var returnType))
	{
	if (invokeMethod.RefKind != refKind ||
	!invokeMethod.ReturnType.Equals(returnType.Type, TypeCompareKind.AllIgnoreOptions))
	{
	return LambdaConversionResult.MismatchedReturnType;
	}
	}

roslyn/src/Compilers/CSharp/Portable/Binder/Semantics/Conversions/ConversionsBase.cs

Lines 1460 to 1469 in 993fcc8

	if (anonymousFunction.HasExplicitlyTypedParameterList)
	{
	for (int p = 0; p < delegateParameters.Length; ++p)
	{
	if (delegateParameters[p].RefKind != anonymousFunction.RefKind(p) ||
	!delegateParameters[p].Type.Equals(anonymousFunction.ParameterType(p), TypeCompareKind.AllIgnoreOptions))
	{
	return LambdaConversionResult.MismatchedParameterType;
	}
	}

However, the success case still depends on binding:

roslyn/src/Compilers/CSharp/Portable/Binder/Semantics/Conversions/ConversionsBase.cs

Lines 1524 to 1531 in 993fcc8

	// Ensure the body can be converted to that delegate type
	var bound = anonymousFunction.Bind(delegateType, isTargetExpressionTree);
	if (ErrorFacts.PreventsSuccessfulDelegateConversion(bound.Diagnostics.Diagnostics))
	{
	return LambdaConversionResult.BindingFailed;
	}
	return LambdaConversionResult.Success;

Is there a reason we need to use PreventsSuccessfulDelegateConversion on this path if both the return type and the parameter types were explicitly given and isTargetExpressionTree is false?

[cston]

There may be edge cases where skipping binding the lambda body might lead to a breaking change, with captured variables for instance.

For example, the following binds to the extension method rather than the instance method, because binding the lambda body fails for the instance method (see sharplab.io).

using System;

class A
{
    static void Main()
    {
        object x = 1;
        var a = new A();
        a.F1(x, y => F2(int () => y));
    }

    void F1<T>(T x, Func<T, int> f) { }
    static int F2(Func<int> f) => f();
}

static class B
{
    public static void F1(this A a, object x, Func<int, int> f) { }
}

[jaredpar]

@cston your example though uses an implicitly typed lambda where as the issue is about explicitly typed lambdas. This is how I would explictly type out that lambda

a.F1(x, int (int y) => F2(int () => y));

At that point why do we need to look at the lambda body here? The instance method is just going to fail at the generic inference phase.

[sharwell]

@jaredpar I believe the failure from @cston example is during type inference for the outer lambda. For inferring the type of y, we can't assume int () => y can be converted to the target delegate based on int () => alone.

[cston]

For the example above, it looks like there would not be a breaking change if the compiler ignored the lambda body when determining whether the inner lambda expression is convertible to the delegate type.

The reason is because the outer lambda is an argument to an overloaded method, and even if we skip binding the body of the inner lambda when determining convertibility to the delegate parameter in F2, and therefore consider F2 applicable, we'll still bind the inner lambda body as a part of determining the convertibility of the outer lambda to the delegate parameter in F1 since the outer lambda is not explicitly typed.

[jaredpar]

Discussed this in LDM today and we confirmed that we want to change behavior here. For a lambda with a full explicit signature (return type and parameters) then for purposes of conversion we will only consider that signature. There is no need to bind the lambda body to see if it matches that signature for the purposes of determining if a conversion is legal.