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

Type inference and lambda binding failure when one method in the group and wrong number of arguments #11901

Closed
gafter opened this issue Jun 9, 2016 · 1 comment

Comments

@gafter
Copy link
Member

gafter commented Jun 9, 2016

The following test (which currently would fail) illustrates that we fail to infer a good target type for a lambda expression argument when there is exactly one method in the method group.

        [Fact]
        [WorkItem(11901, "https://github.com/dotnet/roslyn/issues/11901")]
        public void TestLambdaWithError15()
        {
            // These tests ensure we attempt to perform type inference and bind a lambda expression
            // argument even when there are too many or too few arguments to an invocation, in the
            // case when there is exactly one method in the method group.
            var source =
@"using System;

class Program
{
    static void Main(string[] args)
    {
        Thing<string> t = null;
        t.X1(x => x, 1); // too many args
        t.X2(x => x);    // too few args
        t.M2(string.Empty, x => x, 1); // too many args
        t.M3(string.Empty, x => x); // too few args
    }
}
public class Thing<T>
{
    public void M2<T>(T x, Func<T, T> func) {}
    public void M3<T>(T x, Func<T, T> func, T y) {}
}
public static class XThing
{
    public static Thing<T> X1<T>(this Thing<T> self, Func<T, T> func) => null;
    public static Thing<T> X2<T>(this Thing<T> self, Func<T, T> func, int i) => null;
}
";
            var compilation = CreateCompilationWithMscorlibAndSystemCore(source);
            var tree = compilation.SyntaxTrees[0];
            var sm = compilation.GetSemanticModel(tree);
            foreach (var lambda in tree.GetRoot().DescendantNodes().OfType<LambdaExpressionSyntax>())
            {
                var reference = lambda.Body.DescendantNodesAndSelf().OfType<IdentifierNameSyntax>().First();
                Assert.Equal("x", reference.ToString());
                var typeInfo = sm.GetTypeInfo(reference);
                Assert.Equal(TypeKind.Class, typeInfo.Type.TypeKind);
                Assert.Equal("String", typeInfo.Type.Name);
                Assert.NotEmpty(typeInfo.Type.GetMembers("Replace"));
            }
        }
    }
@gafter gafter self-assigned this Jun 9, 2016
@gafter gafter changed the title Type inference and lambda binding failure when one method in the group Type inference and lambda binding failure when one method in the group and wrong number of arguments Jun 9, 2016
@VSadov VSadov added this to the 2.0 (Preview 1) milestone Jun 11, 2016
gafter added a commit to gafter/roslyn that referenced this issue Jun 14, 2016
@gafter gafter added 4 - In Review A fix for the issue is submitted for review. and removed 3 - Working labels Jun 20, 2016
@gafter gafter modified the milestones: 2.0 (Preview 1), 2.0 (RC) Jun 20, 2016
gafter added a commit that referenced this issue Jun 22, 2016
We attempt to bind lambda args against every applicable delegate
type that could be a matching parameter, and then select the
"best" for error recovery.
This also has the effect of removing unbound lambdas from the
bound trees, replacing them with the "best" binding for error
recovery. This makes the semantic model insensitive to any further
trial bindings (i.e. mutation of the unbound lambda cache).
Fixes #12063, #11979, #11901

Remove vestigal "extensionMethodsOfSameViabilityAreAvailable"
thereby reducing coupling between internal compiler APIs.
See also #7740 #5128, where the vestigal APIs were introduced.
@gafter
Copy link
Member Author

gafter commented Jun 22, 2016

Fixed in 7abdbb5

@gafter gafter closed this as completed Jun 22, 2016
@gafter gafter removed the 4 - In Review A fix for the issue is submitted for review. label Jun 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants