Skip to content

[NativeAOT] Enum.GetValues(Type) should have an aot safe implementation #72140

Description

@LakshanF

We have annotated the above API, public static System.Array GetValues(System.Type enumType), as dangerous (RequiresDynamicCode("It might not be possible to create an array of the enum type at runtime. Use the GetValues<TEnum> overload instead.")).

Consider removing the RDC and providing a native AOT safe implementation.

Activity

  1. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Jul 13, 2022
  2. agocke commented on Jul 14, 2022

    @agocke
    Member

    Looks like this already exists as Enum.GetValues<Type>

  3. ghost removed
    untriagedNew issue has not been triaged by the area owner
    on Jul 14, 2022
  4. LakshanF commented on Jul 14, 2022

    @LakshanF
    ContributorAuthor

    I think we still need an implementation when the source of the type is not known and not able to use the generic one

  5. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Jul 14, 2022
  6. MichalPetryka commented on Jul 14, 2022

    @MichalPetryka
    Contributor

    Well the issue is that AOT generally requires the type to be known since it can't generate code for every enum possible. So I'm not sure if this would be possible without keeping metadata about every enum.

  7. MichalStrehovsky commented on Jul 14, 2022

    @MichalStrehovsky
    Member

    The problem is with creating the array type at runtime, not with "what values to fill in". We keep enough metadata to be able to fill it in.

    We are discussing "fixing" this by having the API return the underlying type of the array. The signature is Array GetValues(Type). It currently returns SomeInt32Enum[] for SomeInt32Enum. But it could also return int[] and still satisfy the contract. There's an upper bound on primitive type arrays and we can pregenerate that.

    We did this in the early days of .NET Native. Backtracked on that, but nobody remembers why. We want to try again :).

  8. Suchiman commented on Jul 14, 2022

    @Suchiman
    Contributor

    @MichalStrehovsky couldn't the TypeLoader dynamically typeload SomeInt32Enum[] by basing it off the underlying type? Given that they have identical layouts and calling conventions, etc.

  9. MichalStrehovsky commented on Jul 14, 2022

    @MichalStrehovsky
    Member

    @MichalStrehovsky couldn't the TypeLoader dynamically typeload SomeInt32Enum[] by basing it off the underlying type? Given that they have identical layouts and calling conventions, etc.

    It would probably leak out from the implementation of generic interfaces on the arrays. Maybe something like cast to IEnumerator(SomeEnum), do GetEnumerator and on the returned enumerator call the non-generic IEnumerator.Current. It would return a boxed Int because it's hardcoded in code. We need shared code over enums to get around that.

  10. added a commit that references this issue on Jul 15, 2022
    031eef9
  11. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Jul 15, 2022
  12. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Jul 20, 2022
  13. MichalStrehovsky commented on Jul 21, 2022

    @MichalStrehovsky
    Member

    #72498 is the way forward for this.

  14. ghost removed
    untriagedNew issue has not been triaged by the area owner
    on Jul 21, 2022
  15. ghost locked as resolved and limited conversation to collaborators on Aug 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

  • Status
    No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions