Preserving operator methods necessary for System.Linq.Expressions

[eerhardt]

Background

There are currently 2 ILLink warnings left in System.Linq.Expressions that both boil down to the same pattern.

When you create a Binary or Unary Expression, and don't specify a MethodInfo, System.Linq.Expressions will try to find an operator on the Type corresponding to the ExpressionType you specified.

For example, if you call Expression.Equal(left, right), will call the following code

        public static BinaryExpression Equal(Expression left, Expression right, bool liftToNull, MethodInfo? method)
        {
            ExpressionUtils.RequiresCanRead(left, nameof(left));
            ExpressionUtils.RequiresCanRead(right, nameof(right));
            if (method == null)
            {
                return GetEqualityComparisonOperator(ExpressionType.Equal, "op_Equality", left, right, liftToNull);
            }

GetEqualityComparisonOperator will look for the op_Equality operator on both the left and right types. This cannot be expressed in the existing trimming annotations because we don't have a System.Type parameter to annotate. left and right are System.Linq.Expressions.Expression instances.

This same pattern applies to pretty much all Binary and Unary expressions:

• Equal
• NotEqual
• Add
• Subtract
• Divide
• Modulo
• Multiply
• Power
• LeftShift
• RightShift
• And
• Or
• Not
• Convert
• Increment
• Decrement
• etc

Proposal

We should add a new rule in the mono/linker that when System.Linq.Expressions is used in an app, it should preserve all user defined operators on Types that are being preserved. This will allow the above Expression code to keep working in a trimmed application.

In the System.Linq.Expressions library, we can then suppress the remaining warnings saying "The trimmer won't trim operators on preserved Types when Expressions are involved. It is safe to try to find these operator methods."

cc @vitek-karas @MichalStrehovsky @marek-safar

[MichalStrehovsky]

Looking at the code the C# compiler generates for Expression<Func<IntPtr>> x = () => IntPtr.Zero + 2;, it generates a call with a non-null method. Could we instead just require whoever calls this API to follow the golden path with a non-null MethodInfo?

We could mark this API as RequiresUnreferencedCode and intrinsically recognize it in linker to make it safe if MethodInfo was provided.

APIs with optional parameters (that have expensive fallbacks for when the parameter wasn't provided) are not very trimming friendly - we should keep that in mind when introducing new APIs in the future. One aspect is situations like this (if this was a separate overload, we could just mark that one as unsafe without having to specialcase in linker). The other aspect is trimming in general - we'll never be able to get rid of the code that tries to find the right operator even if all callers provide a MethodInfo.

[MichalStrehovsky]

We could even go full "nullable annotations" on this and introduce a:

[RequiresUnreferencedCodeWhenNull(nameof(method), "Blah"]

Illink could potentially have an aggressive mode where it would assume method was not null and eliminate the branch that tries to handle the "method == null" case.

[vitek-karas]

I think the problem is for example this:

Expression<Func<int, int, bool>> x = ((int i, int j) => i == j);

This compiles to something like:

Expression.Equal(
    Expression.Parameter(typeof(int), "i"),
    Expression.Parameter(typeof(int), "j"));

There's no method in this case (it will default to null) and the implementation won't find any op_Equality either it will perform intrinsic handling of this case (it know how to compare numeric value types).

Even if we somehow ask everybody to pass in the method, there would be no way to get to the intrinsic handling then, which I assume covers by far the most cases today. I would not be surprised if changing this would break IQueryable providers (I can't see how for example EF could translate an explicit call to custom op_Equality to SQL, it probably fails on it).

The compatibility is another large part of this problem - even if the caller constructs the expression tree in a way which is trim-safe, it doesn't mean the IQueryable provider will be able to handle it. I know that in OData client we explicitly didn't handle LOT of cases, because it was just too expensive to do so - so we asked users to write their queries a certain way. (And also on OData server we had to be very careful crafting the expression trees we passed to EF, or Linq2SQL, even to a degree that the same expression tree didn't work for two different providers and we had to have provider specific code to change the shape of the trees).

The existing IQueryable providers will heavily favor the shapes which Roslyn generates, and so if one of them is not linker-safe, we have a problem.

[MichalStrehovsky]

That makes things more complicated. It makes me wonder though whether we should at least consult how expensive it would be if:

• We were to add new APIs to Expression that don't do the lookup for user defined operators (only work for the built-in types that the APIs handle specially and throw otherwise)
• Would Roslyn have enough type information when building the expression tree that - for the Equals case - it would know that since both left and right side are primitive numeric types, it can use the new API?

If Roslyn has enough type information, this might not be an expensive feature to ask for, and the produced code would be trim safe without acrobatics.

The line between "try to trim as much as possible" and "make sure a lot of code can work" is blurry, but the litmus test I use is whether a layperson would be able to understand why something was kept from our logs. "Expressions were used, therefore we kept all your operators" might be hard to follow. "An unknown method was accessed on this type, therefore we kept all methods on the type" follows more straightforward logic.

[eerhardt]

We were to add new APIs to Expression that don't do the lookup for user defined operators

I'm not sure this approach will be feasible, for the following reasons:

1. The System.Linq.Expressions library is "mature and no longer evolving, and where the risk of code change likely exceeds the benefit". See Archiving stable runtime packages runtime#27790.
2. We have places where we rewrite expressions for various reasons. More or less all of these places would either need to make a breaking change to use the new APIs or be marked RequiresUnreferencedCode. And marking them as unsafe basically turns around and marks a lot of code as RequiresUnreferencedCode.
3. This doesn't fully solve the problem because of the op_False and op_True operators. System.Linq.Expressions dynamically checks that these operators are present and Roslyn doesn't write these operators into the IL like it does for the other operators. For example:

        public struct TC1
        {
            public string Name;
            public int data;

            public TC1(string name, int data)
            {
                Name = name;
                this.data = data;
            }
            public static TC1 operator &(TC1 t1, TC1 t2) { return new TC1("And", 01); }
            public static TC1 operator |(TC1 t1, TC1 t2) { return new TC1("Or", 02); }
            public static TC1 Meth1(TC1 t1, TC1 t2) { return new TC1(); }
            public static bool operator true(TC1? a) { return true; }
            public static bool operator true(TC1 a) { return true; }
            public static bool operator false(TC1? a) { return false; }
            public static bool operator false(TC1 a) { return false; }
        }

TC1? tc1 = new TC1("lhs", 324589);
TC1? tc2 = new TC1("rhs", 324589);

Expression<Func<TC1?>> e = () => tc1 && tc2;

That last line compiles into:

	IL_0078: ldtoken method valuetype TC1 TC1::op_BitwiseAnd(valuetype TC1, valuetype TC1)
	IL_007d: call class [System.Runtime]System.Reflection.MethodBase [System.Runtime]System.Reflection.MethodBase::GetMethodFromHandle(valuetype [System.Runtime]System.RuntimeMethodHandle)
	IL_0082: castclass [System.Runtime]System.Reflection.MethodInfo
	IL_0087: call class [System.Linq.Expressions]System.Linq.Expressions.BinaryExpression [System.Linq.Expressions]System.Linq.Expressions.Expression::AndAlso(class [System.Linq.Expressions]System.Linq.Expressions.Expression, class [System.Linq.Expressions]System.Linq.Expressions.Expression, class [System.Runtime]System.Reflection.MethodInfo)

So the op_BitwiseAnd is referenced in IL. But calling Expression::AndAlso calls into this code, which is dynamically checking for op_True and op_False operators and throws an exception if it can't find them.

[MichalStrehovsky]

Yup, I know about the "no longer evolving" part, but if were to make an API addition that is reasonably easy to review (it just does a subset of an existing API and that's all), it might still be acceptable. It's not like we don't touch the assembly at all.

Looks like there are a bunch of unique problems with the rewriting, so lets see if we can make the rewriting safe at all. If the answer to that ends up being no, then not being able to safely rewrite shouldn't preclude us from being able to safely construct expression trees.

The op_True/op_False issue could be solved by intrinsics (we know what method was passed and these are on the same type). If the method is not known, this wouldn't have been safe either way.

[vitek-karas]

While I appreciate wanting to make this trim compatible for real, there's also a question of "Is it really worth it?".

Just out of curiosity I tried to write a simple version of "mark all operators on all marked types" and ran it on a Blazor template app. It marks 243 operators (which are probably not marked for other reasons - not sure). The compressed size grows by 6KB. That is not ignorable difference in size, on the other hand we would only do this if System.Linq.Expressions was used (or maybe even more precisely we could do it per-operator based on the various places where it's needed, so it could be even more precise).

If this is all it takes to make expression trees work with trimming - I don't think it's that bad. If the app wants to use expression trees, then the price is not crazy high. It will obviously grow with more types which have operators, but still.

[MichalStrehovsky]

I'm more worried about things like conversion operators and not the ones we use in framework. Conversion operators are likely to new up types the app wouldn't ever need.

Decision to root them whenever we see Linq Expressions might come back to bite us.

Here's a bunch of conversion operators that new up things: https://github.com/dotnet/wpf/search?q=%22implicit+operator%22

[eerhardt]

We could also consider making it an option (default it either way, my vote would be "make it safe by default").

That way apps who (1) need to use System.Linq.Expressions and (2) have to trim every bit of possible code out, have a way to turn this off. Of course they would need to be responsible for ensuring their app still behaves correctly after turning the option off. And they would need to manually "mark" any operators that need to be preserved.

[vitek-karas]

We could make the marking of the operators a bit more clever. If class Animal has a conversion operator for Cat, but Cat is not used anywhere in the app, there's no reason to keep such operator (it can't ever be used).

[MichalStrehovsky]

Well, as long as the hack is not more complicated than the Roslyn fix would be, it works for me (if the answer from the Roslyn team would be "we totally know the types of all operands to binary/unary operators" the fix that doesn't doesn't require hardcoding a bunch of Expressions knowledge into illink would probably be less code to maintain).

[eerhardt]

@jaredpar - thoughts in this area? Would the Roslyn team be open to adding new APIs to System.Linq.Expressions and changing how the compiler emits Expressions in order to support trimming?

[jaredpar]

Haven't totally processed the thread but ...

Would the Roslyn team be open to ... and changing how the compiler emits Expressions in order to support trimming?

The problem with expression trees is that APIs which consume expression trees are not tolerant to changes in how the expression trees are emitted. Even tiny changes like adding in a silent conversion node, or when we do or don't cast to make interface calls, irrevocably breaks many of our expression tree consumers.

We learned this lesson with great pain in Roslyn because, for lots of thorny reasons, the expression trees we emitted differed ever so slightly than the ones emitted by the native compiler. This subtle differences broke practically everyone that consumed expression trees. The most notable consumer was the Entity Framework team.

Changing these in place is not really feasible. Even teams like EF Core, who would really like us to expand the set of C# operations that have expression trees, agree we can't change them in place. It requires some sort of API opt-in to acknowledge that the set of trees may be different. Else it would just lead to lots of compat breaks.