Annotate System.Linq.Expressions with RequiresDynamicCode #90456
Conversation
All this ended up with an RUC on Expression.Compile due to new arrays. I could potentially silence this warning with a feature flag, but it is a real risk, and one that users could maybe work around if alterted to the problem.
|
Tagging subscribers to this area: @cston Issue DetailsAll this ended up with an RDC on Expression.Compile due to new arrays. I could potentially silence this warning with a feature flag, but it is a real risk in AOT, and one that users could maybe work around if alerted to the problem.
|
src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Expression.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/NewArrayExpression.cs
Outdated
Show resolved
Hide resolved
| @@ -134,11 +134,15 @@ internal static MethodInfo GetCompileMethod(Type lambdaExpressionType) | |||
| /// Produces a delegate that represents the lambda expression. | |||
| /// </summary> | |||
| /// <returns>A delegate containing the compiled version of the lambda.</returns> | |||
| [RequiresDynamicCode(Expression.NewArrayRequiresDynamicCode)] | |||
There was a problem hiding this comment.
This message is a bit weird (IMO). Anytime someone tries to compile an expression, they will get the warning
"Creating arrays at runtime requires dynamic code generation. This warning can be suppressed if there are no new array nodes in the expression tree."
But won't they already get the warning from the call that actually creates new array nodes in the expression tree? Therefore, we don't need to also warn them at Compile().
There was a problem hiding this comment.
Hmm, hadn't thought of that. The problem is that something like Expression<Func<int[]>> e = () => new[] { 1 }; won't produce an analyzer warning since we don't see the call site, but maybe that can be OK for now and we can treat it as an analyzer improvement to fix later.
There was a problem hiding this comment.
In that case, wouldn't it be fine? There's code there for a new int[].
There was a problem hiding this comment.
Well, maybe. Replace int with your favorite custom struct. That likely wouldn't work.
…ons/Expression.cs Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>
|
@eerhardt Took your suggestion. There's now a suppression at the NewArrayExpression conversion routine. |
src/libraries/System.Linq.Expressions/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
Co-authored-by: Stephen Toub <stoub@microsoft.com>
src/libraries/System.Linq.Expressions/src/System/Dynamic/Utils/TypeUtils.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Linq.Expressions/src/System/Runtime/CompilerServices/CallSiteBinder.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Linq.Expressions/src/System/Dynamic/Utils/TypeUtils.cs
Outdated
Show resolved
Hide resolved
|
@agocke - looks like this just missed the 8.0 cutoff. Do we want to backport this into .NET 8? |
|
I think it would be a good idea, given that people are hitting this in the wild |
|
/backport to release/8.0-rc1 |
|
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5870002616 |
ghost
locked as resolved and limited conversation to collaborators
All this ended up with an RDC on Expression.Compile due to new arrays. I could potentially silence this warning with a feature flag, but it is a real risk in AOT, and one that users could maybe work around if alerted to the problem.