Compiler Crash on Equality Comparison of a Tuple Casted from dynamic

[Jason5Lee]

Version Used: .NET 9.0.0

Steps to Reproduce:

1. Compile the following C# code (SharpLab Link):
   • The code involves casting a dynamic value to a tuple and performing an equality comparison on another tuple.

public class C {
    public static bool Test(dynamic o) =>
        (((int, int))o) == (2, 3);
}

Expected Behavior: The compiler compiles the code without crashes.

Actual Behavior:

• The compilation process fails in Visual Studio with the error:

  "csc.exe" exited with code -2146232797

• Additional details, including a stack trace, are available in the linked SharpLab page.

[jjonescz]

System.InvalidOperationException: Unexpected value 'ExplicitDynamic' of type 'Microsoft.CodeAnalysis.CSharp.ConversionKind'
   at Microsoft.CodeAnalysis.CSharp.CodeGen.CodeGenerator.EmitConversion(BoundConversion conversion)

[RikkiGibson]

Lowering of tuple equality operators has its own code path which visits the operands element-wise, digging through conversions to locate more tuple conversions recursively, in order to compare both tuples element-wise, as the language specifies.

The problem is that the path in LocalRewriter_TupleBinaryOperator.cs which digs through conversions, will lower the conversion operand, but not the conversion itself in some cases. e.g. in the following code, conv's operand is lowered but not conv itself.

roslyn/src/Compilers/CSharp/Portable/Lowering/LocalRewriter/LocalRewriter_TupleBinaryOperator.cs

Lines 199 to 204 in f9ccce0

	case BoundConversion conv:
	{
	// other conversions are deferred
	var deferredOperand = DeferSideEffectingArgumentToTempForTupleEquality(conv.Operand, effects, temps, conv.ExplicitCastInCode || enclosingConversionWasExplicit);
	return conv.UpdateOperand(deferredOperand);
	}

I can't think of a ton of ways to observe this. But casting a dynamic to tuple is one of them. Another would be a fairly contrived case like the following: SharpLab

public void M((Action, Action) dels) {
    _ = ((Action, Action))(object)((Action, Action))(() => {}, () => {}) == dels;
}

So the fix is figuring out how to get LocalRewriter to "visit" the conversion itself, while also preserving its behavior to dig through things element-wise and evaluate to temps. A few possibilities:

1. Do the lowering of the whole conversion node normally, then dig thru it afterwards to find things that need to be stored to temps. This may require changing the DeferSideEffectingArgumentToTempForTupleEquality quite a bit in order to recognize the lowered shapes of things instead of the initial-bound shapes.
2. Extract/duplicate/repurpose code in MakeConversionNodeCore which is handling the specific conversion kinds themselves and reuse it when lowering tuple binary operators.

There may be more options I didn't think of. (2) feels most viable to me as a start.

Tagging @jcouv for thoughts here.

[RikkiGibson]

This bug is likely not a regression and I probably need more assistance in order to be able to solve it.