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

Unexpected semantic information from bad method group conversion in local declaration #75833

Open
jcouv opened this issue Nov 8, 2024 · 2 comments

Comments

@jcouv
Copy link
Member

jcouv commented Nov 8, 2024

There's also similar issue in assignment and possibly in invocations. See tests that refer to this issue.

        [Fact, WorkItem("https://github.com/dotnet/roslyn/issues/75833")]
        public void GetSymbolInfo_ImplicitUserDefinedConversionOnMethodGroup_InLocalDeclaration()
        {
            var src = """
public class C
{
    public static void M()
    {
        C x = C.Test;
    }

    public static int Test() => 1;

    public static implicit operator C(System.Func<int> intDelegate)
    {
        return new C();
    }
}
""";
            var comp = CreateCompilation(src);
            comp.VerifyEmitDiagnostics(
                // (5,17): error CS0428: Cannot convert method group 'Test' to non-delegate type 'C'. Did you intend to invoke the method?
                //         C x = C.Test;
                Diagnostic(ErrorCode.ERR_MethGrpToNonDel, "Test").WithArguments("Test", "C").WithLocation(5, 17));

            var tree = comp.SyntaxTrees.Single();
            var model = comp.GetSemanticModel(tree);
            var memberAccess = GetSyntax<MemberAccessExpressionSyntax>(tree, "C.Test");
            Assert.Equal("C C.op_Implicit(System.Func<System.Int32> intDelegate)", model.GetSymbolInfo(memberAccess).Symbol.ToTestDisplayString());  // Unexpected: Should be null
            var conversion = model.GetConversion(memberAccess);
            Assert.Equal(ConversionKind.ExplicitUserDefined, conversion.Kind); // Unexpected: Should be NoConversion or possibly Identity for error case
            Assert.Equal(ConversionKind.MethodGroup, conversion.UserDefinedFromConversion.Kind);
            Assert.Equal(ConversionKind.Identity, conversion.UserDefinedToConversion.Kind);
        }

        [Fact, WorkItem("https://github.com/dotnet/roslyn/issues/75833")]
        public void GetSymbolInfo_ImplicitUserDefinedConversionOnMethodGroup_WithToConversion_InLocalDeclaration()
        {
            var src = """
public struct C
{
    public static void M()
    {
        C? x = C.Test;
    }

    public static int Test() => 1;

    public static implicit operator C(System.Func<int> intDelegate)
    {
        return new C();
    }
}
""";
            var comp = CreateCompilation(src);
            comp.VerifyEmitDiagnostics(
                // (5,18): error CS0428: Cannot convert method group 'Test' to non-delegate type 'C?'. Did you intend to invoke the method?
                //         C? x = C.Test;
                Diagnostic(ErrorCode.ERR_MethGrpToNonDel, "Test").WithArguments("Test", "C?").WithLocation(5, 18));

            var tree = comp.SyntaxTrees.Single();
            var model = comp.GetSemanticModel(tree);
            var memberAccess = GetSyntax<MemberAccessExpressionSyntax>(tree, "C.Test");
            Assert.Null(model.GetSymbolInfo(memberAccess).Symbol);
            var conversion = model.GetConversion(memberAccess);
            Assert.Equal(ConversionKind.ExplicitUserDefined, conversion.Kind); // Unexpected: Should be NoConversion or possibly Identity for error case
            Assert.Equal(ConversionKind.MethodGroup, conversion.UserDefinedFromConversion.Kind);
            Assert.Equal(ConversionKind.Identity, conversion.UserDefinedToConversion.Kind);
        }
@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Issues and PRs which have not yet been triaged by a lead label Nov 8, 2024
@jaredpar
Copy link
Member

How impactful is this issue? Is there a reason we didn't address it with the other fix for method group conversions?

@jcouv
Copy link
Member Author

jcouv commented Nov 11, 2024

This is less impactful than the scenario that was fixed because this is an error scenario. Also, this scenario doesn't go through the codepath that was affected in that fix/PR, so it was better to separate.

@jaredpar jaredpar removed the untriaged Issues and PRs which have not yet been triaged by a lead label Nov 14, 2024
@jaredpar jaredpar added this to the Backlog milestone Nov 14, 2024
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