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

ContainingSymbol for substituted local function seems incorrect #75543

Open
jcouv opened this issue Oct 17, 2024 · 0 comments
Open

ContainingSymbol for substituted local function seems incorrect #75543

jcouv opened this issue Oct 17, 2024 · 0 comments
Labels
Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead

Comments

@jcouv
Copy link
Member

jcouv commented Oct 17, 2024

Given the behavior in non-generic case, I expected that the ContainingSymbol should be the containing method in the generic scenario. But the containing type is returned instead.
It looks like SubstitutedMethodSymbol uses the same value for both ContainingType and ContainingSymbol.

        [Fact]
        public void ContainingSymbol_ConstructedLocalFunction()
        {
            var source = """
public class C
{
    public void M()
    {
        local(new C());
        void local<T>(T t) { }
    }
}
""";
            var comp = CreateCompilation([source]);
            comp.VerifyDiagnostics();

            var tree = comp.SyntaxTrees.Single();
            var model = comp.GetSemanticModel(tree);
            var invocation = GetSyntax<InvocationExpressionSyntax>(tree, "local(new C())");
            var symbol = model.GetSymbolInfo(invocation).Symbol;
            Assert.Equal("void local<C>(C t)", symbol.ToTestDisplayString());
            Assert.Equal("C", symbol.ContainingSymbol.ToTestDisplayString()); // We're returning the containing type here, instead of the containing symbol (ie. the containing method)
        }

        [Fact]
        public void ContainingSymbol_LocalFunction()
        {
            var source = """
public class C
{
    public void M()
    {
        local();
        void local() { }
    }
}
""";
            var comp = CreateCompilation([source]);
            comp.VerifyDiagnostics();

            var tree = comp.SyntaxTrees.Single();
            var model = comp.GetSemanticModel(tree);
            var invocation = GetSyntax<InvocationExpressionSyntax>(tree, "local()");
            var symbol = model.GetSymbolInfo(invocation).Symbol;
            Assert.Equal("void local()", symbol.ToTestDisplayString());
            Assert.Equal("void C.M()", symbol.ContainingSymbol.ToTestDisplayString());
        }
@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Issues and PRs which have not yet been triaged by a lead label Oct 17, 2024
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

No branches or pull requests

1 participant