Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid binding lambda body if fully typed #69505

Closed
wants to merge 3 commits into from

Conversation

jjonescz
Copy link
Member

Resolves #69093.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Aug 15, 2023
@jjonescz jjonescz marked this pull request as ready for review August 15, 2023 10:25
@jjonescz jjonescz requested a review from a team as a code owner August 15, 2023 10:25
public static void F1(this A a, object x, Func<int, int> f) => Console.Write("B");
}
""";
CompileAndVerify(source, expectedOutput: "B").VerifyDiagnostics();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cston wasn't 100% sure this would be the result after he reflected on the proposed change. Wanted to make sure he saw this.

Copy link
Member

@cston cston Aug 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this looks correct to me - no change in behavior. (I took a second look at this case and realized my initial thought was incomplete.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the test call the ClassifyConversion API here? Including a case where the lambda body is of the wrong type but explicit return is the expected type?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, should we add a new EndToEnd test which shows that the change results in "viable" perf in the relevant scenario?

Copy link
Member Author

@jjonescz jjonescz Aug 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, should we add a new EndToEnd test which shows that the change results in "viable" perf in the relevant scenario?

Thanks, trying to write such test made me realize this might not be a complete fix (or maybe not easily fixable at all).

For example, when type inference is involved, lambdas are bound later anyway for error recovery

var discarded = unboundArgument.Bind((NamedTypeSymbol)parameterType, isExpressionTree: false);

or simply when overload resolution binds the arguments:

var boundLambda = unboundLambda.Bind((NamedTypeSymbol)destination, isExpressionTree: destination.IsGenericOrNonGenericExpressionType(out _)).WithInAnonymousFunctionConversion();

Hence the change currently in this PR doesn't seem to improve anything in my testing. Will investigate more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, should we add a new EndToEnd test which shows that the change results in "viable" perf in the relevant scenario?

#59733 includes a change to track the number of unbound lambdas and number of times lambda expressions are bound. Would something similar be useful here for measuring the impact?

var targetType = comp.GetMember<MethodSymbol>("C.M2").Parameters.Single().Type.GetPublicSymbol();
Assert.Equal("System.Func<System.Int32>", targetType.ToTestDisplayString());
var conversion = model.ClassifyConversion(lambdaSyntax, targetType);
Assert.True(conversion.IsValid);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: this would be false without the change in this PR.

@jjonescz jjonescz marked this pull request as draft August 17, 2023 08:35
@jjonescz jjonescz closed this Nov 3, 2023
@jjonescz jjonescz deleted the 69093-FullyTypedLambda branch November 3, 2023 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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