Make LINQ providers (Queryable) compatible with NativeAOT

[roji]

The queryable LINQ operators are currently marked with [RequiresDynamicCode] (e.g. Where), because their implementation uses MakeGenericType. This makes them incompatible with NativeAOT.

In typical LINQ providers, the expression tree doesn't end up getting compiled and executed, but rather translated to something else (e.g. SQL); this means that the Types and MethodInfos in the tree are only there for the proper tree structure, and we don't need them to actually contain code. However, MakeGenericType and MakeGenericMethod are currently eager, and throw right away in NativeAOT if the native code isn't pregenerated.

To solve this, we'd need to be able to make lazy Types, MethodInfos, which only throw if a method/property is actually invoked on them. From a conversation with @jkotas, the eager behavior of the reflection types was done in order to provide fail-fast behavior to users; we could revisit this decision.

As an alternative, since Type/MethodInfo/PropertyInfo are abstract base classes, we could add lazy implementations of these. These implementations could either throw if code is invoked, or lazily call the real MakeGenericMethod when needed (which would fail in NativeAOT). Construction of these lazy types should be exposed as a new API, since LINQ providers such as EF would need to make use of them as well (otherwise LINQ providers would need to duplicate the lazy types internally).

Thanks for @jkotas for the suggestions and conversation.

/cc @ajcvickers @AndriySvyryd

Tagging subscribers to this area: @cston
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The queryable LINQ operators are currently marked with [RequiresDynamicCode] (e.g. Where), because their implementation uses MakeGenericType. This makes them incompatible with NativeAOT.

In typical LINQ providers, the expression tree doesn't end up getting compiled and executed, but rather translated to something else (e.g. SQL); this means that the Types and MethodInfos in the tree are only there for the proper tree structure, and we don't need them to actually contain code. However, MakeGenericType and MakeGenericMethod are currently eager, and throw right away in NativeAOT if the native code isn't pregenerated.

To solve this, we'd need to be able to make lazy Types, MethodInfos, which only throw if a method/property is actually invoked on them. From a conversation with @jkotas, the eager behavior of the reflection types was done in order to provide fail-fast behavior to users; we could revisit this decision.

As an alternative, since Type/MethodInfo/PropertyInfoare abstract base classes, we could add lazy implementations of these. These implementations could either throw if code is invoked, or lazily call the real MakeGenericMethod when needed (which would fail in NativeAOT). Construction of these lazy types should be exposed as a new API, since LINQ providers such as EF would need to make use of them as well (otherwise LINQ providers would need to duplicate the lazy types internally).

Thanks for @jkotas for the suggestions and conversation.

/cc @ajcvickers @AndriySvyryd

Author:	roji
Assignees:	-
Labels:	area-System.Linq.Expressions
Milestone:	-

[jkotas]

The challenge is how to differentiate the Linq queries that are acting as a template for Linq providers like EF Core from the Linq queries that are going to be executed at runtime. We still want to have RequiresDynamicCode warning for the Linq queries that are executed at runtime. The warning is produced when as the query is being built today. If we made the clause building AOT compatible by constructing the required types lazily, where would the RequiresDynamicCode annotation moved for runtime execution so that the analyzers can still warn you?

the expression tree doesn't end up getting compiled and executed, but rather translated to something else (e.g. SQL); this means that the Types and MethodInfos in the tree are only there for the proper tree structure, and we don't need them to actually contain code.

This problem may be actually another case for callsite rewriting that we are designing for make other ASP.NET dynamic patterns compatible with native AOT (@jaredpar has been working on the design). The idea is to allow source generators to replace the user-written code with a different code that is AOT compatible. For example, it can replace the call to the standard IQueryable Where method with a call to a different Where method that instantiates the generic types lazily, that is only usable as a template EF Core query and never executed at runtime, and that does not have the RequiresDynamicCode annotation.

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The queryable LINQ operators are currently marked with [RequiresDynamicCode] (e.g. Where), because their implementation uses MakeGenericType. This makes them incompatible with NativeAOT.

In typical LINQ providers, the expression tree doesn't end up getting compiled and executed, but rather translated to something else (e.g. SQL); this means that the Types and MethodInfos in the tree are only there for the proper tree structure, and we don't need them to actually contain code. However, MakeGenericType and MakeGenericMethod are currently eager, and throw right away in NativeAOT if the native code isn't pregenerated.

To solve this, we'd need to be able to make lazy Types, MethodInfos, which only throw if a method/property is actually invoked on them. From a conversation with @jkotas, the eager behavior of the reflection types was done in order to provide fail-fast behavior to users; we could revisit this decision.

As an alternative, since Type/MethodInfo/PropertyInfoare abstract base classes, we could add lazy implementations of these. These implementations could either throw if code is invoked, or lazily call the real MakeGenericMethod when needed (which would fail in NativeAOT). Construction of these lazy types should be exposed as a new API, since LINQ providers such as EF would need to make use of them as well (otherwise LINQ providers would need to duplicate the lazy types internally).

Thanks for @jkotas for the suggestions and conversation.

/cc @ajcvickers @AndriySvyryd

Author:	roji
Assignees:	-
Labels:	area-System.Linq.Expressions, untriaged, area-NativeAOT-coreclr
Milestone:	-

[roji]

Yeah. My idea here was indeed to check RuntimeFeature.IsDynamicCodeSupported in the implementation of e.g. Queryable.Where, and return the lazy version accordingly. And yeah, RequiresDynamicCode is the problem here.

First, it doesn't seem right to warn about the LINQ provider requiring dynamic code via the queryable operators; the real question is whether the LINQ provider itself is compatible or not. For example, someone can just as well enumerate the query root without composing any operators on it:

_ = efcontext.Blogs.ToList();

There's no operator being composed in the query, although the LINQ provider may definitely not be AOT-compatible. This is maybe an edge case; but the interesting thing really is whether the provider requires dynamic code to execute the query rather than the detail of how the operators are created when composing them in the expression tree.

Unfortunately, given the design of it all - I'm not sure how that can be done; the LINQ provider is basically like an IEnumerable whose enumerator implementation needs dynamic code. There's simply no good place to handle this AFAICT. As far as I know there's no assembly attribute that can tell us whether a dependency has declared itself compatible with AOT (and which would activate the analyzer when building it), right?

Tagging @eerhardt too.

[jkotas]

As far as I know there's no assembly attribute that can tell us whether a dependency has declared itself compatible with AOT

There is not one today. I do not think it would help to solve this problem even if it existed. The analyzer that runs at publish time has to always analyze the whole app for the result to be meaningful.

[roji]

I do not think it would help to solve this problem even if it existed. The analyzer that runs at publish time has to always analyze the whole app for the result to be meaningful.

Ah, I didn't have the right picture in mind (so I'm guessing that the warnings I'm getting while running the code are only a subset of the warnings I'd get at publish time, just like with trimming?).

If the entire app is analyzed at publish time, and an old LINQ provider package uses code generation somewhere, then won't that generate a warning in any case (since the provider code internally uses dynamic code generation without propagating [RequiresDynamicCode])? If that's the case, that seems good enough (the user is notified the provider isn't compatible), and we don't need the warnings from the operators?

[jkotas]

There are no warnings at runtime. It is just going to crash or misbehave at runtime. We want to guarantee that there is always a warning at build time if the code crashes or misbehaves at runtime due to trimming or AOT problem.

You can move where warnings are reported by suppressing them in one place and reporting them at different place (typically earlier) instead. We use this strategy in the dotnet/runtime in some places. Here is one random example:

runtime/src/libraries/System.Net.Http.Json/src/System/Net/Http/Json/JsonContent.cs

Lines 66 to 69 in 8e2a059

	[UnconditionalSuppressMessage("ReflectionAnalysis", "IL2026:RequiresUnreferencedCode",
	Justification = "The ctor is annotated with RequiresUnreferencedCode.")]
	[UnconditionalSuppressMessage("AotAnalysis", "IL3050:RequiresDynamicCode",
	Justification = "The ctor is annotated with RequiresDynamicCode.")]

. Notice that there is Justification that explains why the warning suppression is sound.

an old LINQ provider package uses code generation somewhere, then won't that generate a warning in any case (since the provider code internally uses dynamic code generation without propagating [RequiresDynamicCode])? If that's the case, that seems good enough (the user is notified the provider isn't compatible), and we don't need the warnings from the operators?

Can somebody use the operators with a LINQ provider that does not use any dynamic code? If the operators use the dynamic code and the warnings on them are suppressed, where is the warning going to be instead in this situation?

[roji]

There are no warnings at runtime. It is just going to crash or misbehave at runtime. We want to guarantee that there is always a warning at build time if the code crashes or misbehaves at runtime due to trimming or AOT problem.

Right. But that's my point - if you use any LINQ provider the does dynamic code generation, don't you already get a build-time warning for the places where that provider does that? If so, that seems to remove the need for warnings from the construction of the operators (and indeed, the real problem isn't with them, it's with what the provider does with them - whether it compiles/invokes them or not).

Can somebody use the operators with a LINQ provider that does not use any dynamic code? If the operators use the dynamic code and the warnings on them are suppressed, where is the warning going to be instead in this situation?

That's ideally the plan for EF Core 8.0 - no actual runtime code generation would take place (since it will have been generated at build time), but various expression tree processing must still occur (e.g. to generate SQL from that tree). For other providers which do use dynamic code, I'd expect the warning to come from the use of Expression<TDelegate>.Compile(), MethodInfo.Invoke, etc. In other words, move the warning from the construction of the LINQ operators to when code is actually invoked.

[jkotas]

move the warning from the construction of the LINQ operators to when code is actually invoked.

We would also have to move the construction of the problematic generic types from the construction of the LINQ operators to when code is actually invoked. The construction of the operators would have to be switched to use place holders for generic types, and the actual generic types would get fully inflated only once the LINQ provider tries to compile or run the query.

[roji]

Yeah, that's exactly what I have in mind; the construction of the queryable LINQ operators would check RuntimeFeature.IsDynamicCodeSupported, and if it's false, return a lazy implementation of MethodInfo for Where.

Since others are going to need to do this as well (e.g. custom LINQ operators that EF providers), we'd ideally provide a runtime API that returns these (e.g. an overload of MakeGenericType/Method which accepts a lazy flag parameter)?

In a sense, this introduces a bit of AOT laziness around Type and MethodInfo (allow constructing them but not invoking stuff on them), specifically within the context of LINQ providers (because LINQ providers don't necessary execute the expressions). Of course, if we wanted to consider making Type/MethodInfo lazy in general in AOT, we wouldn't need this.