Skip to content

Rules for more aggressive reflection metadata removal #656

@MichalStrehovsky

Description

@MichalStrehovsky

We currently generate reflection metadata for everything that has code. With the trimming warnings and annotations, we might be able to be more aggressive. This is a running list of invariants that various suppressions rely on:

  • The Invoke method on delegates always has metadata
  • All virtual method overloads have metadata if one of them has metadata (suppressions around e.g. inherited custom attributes or LINQ expressions rely on that)
  • If Nullable<T> has a full EEType, so has the T (this is suppressions around constructors for the T, but since T is valuetype, constructors might just mean "treat as boxed")
  • Literal fields on enums are always available
  • Template type loader is able to create arrays of reference types
  • If we have an EEType of an interface, the types that have the EEType in their interface list need to keep it in their interface list. This also applies to generic interfaces and for those having the definition (uninstantiated) EEType is enough to keep the instantiated one in the interface list.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-NativeAOT-coreclr.NET runtime optimized for ahead of time compilation

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions