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.

Sign up for GitHub

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

Jump to bottom

Unexpected IInvalidOperation for ref returning property as a target of member initializer #72916

Closed
AlekseyTs opened this issue Apr 7, 2024 · 0 comments · Fixed by #73243
Closed

Unexpected IInvalidOperation for ref returning property as a target of member initializer #72916

AlekseyTs opened this issue Apr 7, 2024 · 0 comments · Fixed by #73243
Assignees
@jjonescz
Labels
Area-Compilers Bug Feature - IOperation IOperation New Language Feature - Ref Locals and Returns Ref Locals and Returns
Milestone
17.11

Comments

@AlekseyTs
Copy link
Contributor 

        [Fact]
        public void Test()
        {
            string source = @"
public class C
{
    public static void Main()
    {
        var c = new C() { [1] = 2 };
        System.Console.WriteLine(c[1]);        
    }

    int _test1 = 0;    
    ref int this[int x]
    {
        get => ref _test1;
    }
}
";

            var comp = CreateCompilation(source, options: TestOptions.DebugExe, targetFramework: TargetFramework.StandardAndCSharp);

            CompileAndVerify(comp, expectedOutput: "2").VerifyDiagnostics();

            var tree = comp.SyntaxTrees.Single();
            var model = comp.GetSemanticModel(tree);

            var elementAccess = tree.GetRoot().DescendantNodes().OfType<ImplicitElementAccessSyntax>().Single();
            var propertyRef = (IPropertyReferenceOperation)model.GetOperation(elementAccess);
        }

Observed:

System.InvalidCastException : Unable to cast object of type 'Microsoft.CodeAnalysis.Operations.InvalidOperation' to type 'Microsoft.CodeAnalysis.Operations.IPropertyReferenceOperation'.

Expected:
No errors. This is a success scenario, there should be no IInvalidOperation in the tree.

Should check VB behavior as well.
@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Issues and PRs which have not yet been triaged by a lead label Apr 7, 2024
@AlekseyTs AlekseyTs mentioned this issue Apr 7, 2024
Closed
@jaredpar jaredpar added Bug and removed untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 8, 2024
@jaredpar jaredpar added this to the 17.11 milestone Apr 8, 2024
AlekseyTs added a commit that referenced this issue Apr 11, 2024
@AlekseyTs
Restore dynamic as result type of some operations involving `dynami…
5a49045 
…c` arguments (#72964)

Fixes #72750.

For C# 12 language version: behavior of the compiler in regards to deciding between whether binding should be static or dynamic is the same as behavior of C# 12 compiler. As a result, for affected scenarios, what used to have `dynamic` type in C# 12 compiler will have `dynamic` type when C# 12 language version is targeted.

For newer language versions: invocations statically bound in presence of dynamic arguments should have dynamic result if their dynamic binding succeeded in C# 12. Corresponding spec update - dotnet/csharplang#8027 at commit 8.

Related to #33011, #72906, #72912, #72913, #72914, #72916, #72931.
AlekseyTs added a commit to AlekseyTs/roslyn that referenced this issue Apr 16, 2024
@AlekseyTs
Restore dynamic as result type of some operations involving `dynami…
6291b1c 
…c` arguments (dotnet#72964)

Fixes dotnet#72750.

For C# 12 language version: behavior of the compiler in regards to deciding between whether binding should be static or dynamic is the same as behavior of C# 12 compiler. As a result, for affected scenarios, what used to have `dynamic` type in C# 12 compiler will have `dynamic` type when C# 12 language version is targeted.

For newer language versions: invocations statically bound in presence of dynamic arguments should have dynamic result if their dynamic binding succeeded in C# 12. Corresponding spec update - dotnet/csharplang#8027 at commit 8.

Related to dotnet#33011, dotnet#72906, dotnet#72912, dotnet#72913, dotnet#72914, dotnet#72916, dotnet#72931.
@AlekseyTs AlekseyTs mentioned this issue Apr 16, 2024
Merged
AlekseyTs added a commit that referenced this issue Apr 17, 2024
@AlekseyTs
Port #72964 to release/dev17.10 (#73058)
3af0081 
Restore dynamic as result type of some operations involving dynamic arguments (#72964)

Fixes #72750.

For C# 12 language version: behavior of the compiler in regards to deciding between whether binding should be static or dynamic is the same as behavior of C# 12 compiler. As a result, for affected scenarios, what used to have dynamic type in C# 12 compiler will have dynamic type when C# 12 language version is targeted.

For newer language versions: invocations statically bound in presence of dynamic arguments should have dynamic result if their dynamic binding succeeded in C# 12. Corresponding spec update - dotnet/csharplang#8027 at commit 8.

Related to #33011, #72906, #72912, #72913, #72914, #72916, #72931.
@jjonescz jjonescz mentioned this issue Apr 26, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jjonescz jjonescz

Labels
Area-Compilers Bug Feature - IOperation IOperation New Language Feature - Ref Locals and Returns Ref Locals and Returns
Projects
None yet
Milestone
17.11
Development

Successfully merging a pull request may close this issue.

Fix IOperation of byref member initializer jjonescz/roslyn
3 participants
@jaredpar @jjonescz @AlekseyTs