Respect IsDynamicCodeSupported in more places in Linq.Expressions #88539
Conversation
* CanEmitObjectArrayDelegate * CanCreateArbitraryDelegates These properties are all set to `false` when running on NativeAOT, so have them respect RuntimeFeature.IsDynamicCodeSupported. Fix dotnet#81803
…sting in CoreClr's System.Private.CoreLib. Allow System.Linq.Expressions to create an object[] delegate using Ref.Emit even though RuntimeFeature.IsDynamicCodeSupported is set to false (ex. using a feature switch). To enable this, add an internal method in CoreLib that temporarily allows the current thread to skip the RuntimeFeature check and allows DynamicMethod instances to be created. When System.Linq.Expressions needs to generate one of these delegates, it calls the internal method through Reflection and continues to use Ref.Emit to generate the delegate.
eerhardt
requested review from
333fred,
jkotas,
cston,
MichalStrehovsky and
buyaa-n
|
Tagging subscribers to this area: @cston Issue Details
These properties are all set to However, CanEmitObjectArrayDelegate needs a work around because DynamicDelegateAugments.CreateObjectArrayDelegate does not exist in CoreClr's System.Private.CoreLib. Allow System.Linq.Expressions to create an object[] delegate using Ref.Emit even though RuntimeFeature.IsDynamicCodeSupported is set to false (ex. using a feature switch). To enable this, add an internal method in CoreLib that temporarily allows the current thread to skip the RuntimeFeature check and allows DynamicMethod instances to be created. When System.Linq.Expressions needs to generate one of these delegates, it calls the internal method through Reflection and continues to use Ref.Emit to generate the delegate. Fix #81803
|
src/libraries/System.Linq.Expressions/src/System/Dynamic/Utils/DelegateHelpers.cs
Show resolved
Hide resolved
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| // This can be flipped to true using feature switches at publishing time | ||
| // This can be flipped to false using feature switches at publishing time | ||
| internal static bool CanEmitObjectArrayDelegate => true; |
There was a problem hiding this comment.
Would it make sense to change this into
internal static bool CanEmitObjectArrayDelegate => RuntimeFeature.CanEmitObjectArrayDelegate;If it remains a constant value it will still cause issues for iOS-like platforms as described in: #87924
My last comment: #87924 (comment) breaks down the benefits of having these conditional variables as feature switches.
There was a problem hiding this comment.
I think that would be a good enhancement to make in a future PR. It isn't necessary to fix the issue this PR is fixing - #81803.
|
Frozen collection test failures in NativeAOT builds are #88628. |
src/libraries/System.Linq.Expressions/src/System/Dynamic/Utils/DelegateHelpers.cs
Outdated
Show resolved
Hide resolved
|
Failure is #88582. |
ghost
locked as resolved and limited conversation to collaborators
These properties are all set to
falsewhen running on NativeAOT, so have them respect RuntimeFeature.IsDynamicCodeSupported when not running on NativeAOT.However, CanEmitObjectArrayDelegate needs a work around because DynamicDelegateAugments.CreateObjectArrayDelegate does not exist in CoreClr's System.Private.CoreLib.
Allow System.Linq.Expressions to create an object[] delegate using Ref.Emit even though RuntimeFeature.IsDynamicCodeSupported is set to false (ex. using a feature switch). To enable this, add an internal method in CoreLib that temporarily allows the current thread to skip the RuntimeFeature check and allows DynamicMethod instances to be created. When System.Linq.Expressions needs to generate one of these delegates, it calls the internal method through Reflection and continues to use Ref.Emit to generate the delegate.
Fix #81803