Unexpected indirect load instruction is emitted for ref assignment to a discard

[AlekseyTs]

        [Fact, WorkItem("https://github.com/dotnet/roslyn/issues/79051")]
        public void Test2()
        {
            var source = """
                class C
                {
                    void M(ref byte b1)
                    {
                        _ = ref b1;
                    }
                }
                """;
            CompileAndVerify(source, options: TestOptions.DebugDll).VerifyIL("C.M", """
                {
                  // Code size        5 (0x5)
                  .maxstack  1
                  IL_0000:  nop
                  IL_0001:  ldarg.1
                  IL_0002:  ldind.u1
                  IL_0003:  pop
                  IL_0004:  ret
                }
                """);
            CompileAndVerify(source, options: TestOptions.ReleaseDll).VerifyIL("C.M", """
                {
                  // Code size        4 (0x4)
                  .maxstack  1
                  IL_0000:  ldarg.1
                  IL_0001:  ldind.u1
                  IL_0002:  pop
                  IL_0003:  ret
                }
                """);
        }

        [Fact, WorkItem("https://github.com/dotnet/roslyn/issues/79051")]
        public void Test3()
        {
            var source = """
                class C
                {
                    void M()
                    {
                        ref byte b1 = ref GetRef();
                        _ = ref b1;
                    }

                    static ref byte GetRef() => throw null;
                }
                """;
            CompileAndVerify(source, options: TestOptions.DebugDll).VerifyIL("C.M", """
                {
                  // Code size       11 (0xb)
                  .maxstack  1
                  .locals init (byte& V_0) //b1
                  IL_0000:  nop
                  IL_0001:  call       "ref byte C.GetRef()"
                  IL_0006:  stloc.0
                  IL_0007:  ldloc.0
                  IL_0008:  ldind.u1
                  IL_0009:  pop
                  IL_000a:  ret
                }
                """);
            CompileAndVerify(source, options: TestOptions.ReleaseDll).VerifyIL("C.M", """
                {
                  // Code size        8 (0x8)
                  .maxstack  1
                  IL_0000:  call       "ref byte C.GetRef()"
                  IL_0005:  ldind.u1
                  IL_0006:  pop
                  IL_0007:  ret
                }
                """);
        }

[copilot-swe-agent]

The agent encountered an error and was unable to start working on this issue: This may be caused by a repository ruleset violation. See granting bypass permissions for the agent, or please contact support if the issue persists. (Request id: F408:1D1E27:38E483C:2D49149:6A6CAE63)

[AlekseyTs]

I added a bunch of tests for ref assignments to a discard in commit AlekseyTs@3c12c34. It looks like for such assignments we should assume that a readonly reference is requested for the right hand side. Right now, compiler isn't consistent, but, at least for scenario in added RefDiscardAssignment_15_Conditional it uses a readonly reference. Therefore, strengthening to a writable reference can break an existing code.

Why things are the way they are today? LocalRewriter.MakeStaticAssignmentOperator replaces the assignment with rewritten right:

            switch (rewrittenLeft.Kind)
            {
                ...
                case BoundKind.DiscardExpression:
                    {
                        return rewrittenRight;
                    }

Right now, we do not have a bound node that represents an operation of taking a ref of an LValue. The fact that we need a ref is actually stored in a BoundAssignmentOperator.IsRef property and the readonly/writable flavor is inferred from RefKind of the left hand side.
Effectively, replacing BoundAssignmentOperator with just its right hand side, an unused ref is replaced with an unused value. But unused value and unused reference have different side effects that should be preserved.

We were successful for so long in avoiding an introduction of a bound node that represents an operation of taking a ref. Mostly because we didn't want to update various visitors/rewriters to handle it. For example, we added BoundConditionalOperator.IsRef property instead. Unfortunately that means that we are unable to represent semantics for some scenarios with required degree of accuracy. Perhaps it is time to finally add the node and get rid of IsRef flags.