This addresses issue #11740 on stack spilling limitations when dealing with ref parameters and value type instances. Dealing with this restriction manually can be quite bothersome; I've run into this personally when building a (de)serialization framework that emits expression trees for efficiency. However, when value types are involved and the generated expression uses Try nodes, it's easy to fall victim to this restriction.

A trivial example of this limitation is shown below:

var dt = Parameter(typeof(DateTimeOffset));

var e =
    Lambda<Func<DateTimeOffset, DateTimeOffset>>(
        Call(
            // a value type instance
            dt,
            typeof(DateTimeOffset).GetMethod(nameof(DateTimeOffset.AddYears)),
            // causes stack spilling
            TryFinally(
                Constant(1),
                Empty()
            )
        ),
        dt
    );

// throws NotSupportedException
var f = e.Compile();

The code throws the following exception:

Unhandled Exception: System.NotSupportedException: TryExpression is not supported as a child expression when accessing a member on type 'System.DateTimeOffset' because it is a value type. Construct the tree so the TryExpression is not nested inside of this expression.
   at System.Linq.Expressions.Compiler.StackSpiller.RequireNotRefInstance(Expression instance)
   at System.Linq.Expressions.Compiler.StackSpiller.RewriteMethodCallExpression(Expression expr, Stack stack)
   at System.Linq.Expressions.Compiler.StackSpiller.RewriteExpression(Expression node, Stack stack)
   at System.Linq.Expressions.Compiler.StackSpiller.RewriteExpressionFreeTemps(Expression expression, Stack stack)
   at System.Linq.Expressions.Compiler.StackSpiller.Rewrite[T](Expression`1 lambda)
   at System.Linq.Expressions.Compiler.LambdaCompiler.Compile(LambdaExpression lambda, DebugInfoGenerator debugInfoGenerator)
   at System.Linq.Expressions.Expression`1.Compile()

Dealing with this in the suggested way requires an overhaul of the generated expression tree. Lifting this restriction seems worth the effort.

The approach used in this PR is as follows:

• Rather than throwing an exception from RequireNotRefInstance or RequireNoRefArgs, we use all these places to record the child expression's index of the value type instance or ref argument in the ChildRewriter instance.
• When analysis of child expressions is done and the rewrite action is SpillStack, temporary variables for the spilled child expressions are created. The recorded ref information (by child expression index) is consulted to decide on whether to use a ByRef type instead.
• In order to store a reference to a value to a ByRef temporary variable, a new internal-only RefExpression is used as the right-hand side of the assignment. This node behaves much like ref locals in C# 7.0.
• The LambdaCompiler knows about the occurrence of ref locals and emits valid IL when encountering these. For example, rather than emitting ldloca to obtain a reference to a value-typed local, it can emit ldloc in case the local is a ref local introduced by spilling.

Note that the use of an internal-only extension node is similar to the already existing internal-only SpilledExpressionBlock introduced by the stack spiller as well. These node types are only introduced during stack spilling and never leak to the user.

For the example shown above, the rewritten expression tree after stack spilling looks like:

var dt = Parameter(typeof(DateTimeOffset));
var t1 = Parameter(typeof(DateTimeOffset).MakeByRefType(), "$temp$0");
var t2 = Parameter(typeof(int), "$temp$1");

var e =
    Lambda<Func<DateTimeOffset, DateTimeOffset>>(
        Block(
            new[] { t1, t2 },
            // save `ref dt` to a temporary variable
            Assign(
                t1,
                new RefExpression(dt)
            ),
            Assign(
                t2,
                TryFinally(
                    Constant(1),
                    Empty()
                )
            ),
            Call(
                // emit for Call supports ref locals
                t1,
                typeof(DateTimeOffset).GetMethod(nameof(DateTimeOffset.AddYears)),
                t2
            )
        ),
        dt
    )
)

Note that the construction of the rewritten expression tree during stack spilling does not use the Expression factory methods; instead, it uses Make methods and constructors on the node types. This enables nodes such as Call, Member, etc. to be constructed where the target instance or any arguments are ByRef types. The factory methods don't support these (and we don't want to change that now), but the changes to the LambdaCompiler emit functionality support the use of ByRef types in these positions (see EmitInstance and AddressOf changes).

For the running example, the emitted IL code looks more or less like this:

.method valuetype System.DateTimeOffset lambda_method(valuetype System.DateTimeOffset)
{
    .locals init (
        [0] valuetype System.DateTimeOffset&,
        [1] int32,
        [2] int32
    )

    // spilling of instance (cf. EmitAddress)
    ldarga.0
    stloc.0   // $temp$0

    // evaluation stack empty, as required
    .try
    {
        ldc.i4.1
        stloc.2
        leave E
    }
    finally
    {
        endfinally
    }
E:
    ldloc.2
    stloc.1   // $temp$1

    // perform the call in spilled operands
    ldloc.0
    ldloc.1
    call valuetype System.DateTimeOffset System.DateTimeOffset::AddYears(int32)
    ret
}

This PR lifts the "no ref" restriction in pretty much all places, except for:

• Arguments passed to Method of BinaryExpression and UnaryExpression (when can ByRef occur here?)
• Arguments passed to the Invoke method of a dynamic call site (to be reviewed)
• Instance of MemberExpression where Member is a property (what's there to spill in this case?)

Many IL-level tests are included. Issue #13007 was uncovered by doing this work.

CC @VSadov