Only generic scenarios that can be resolved and compiled at build time are supported in NativeAOT. So, the statement that “all generic scenarios are supported” is overly broad. I’ll try to avoid such assumptions :).
ILLink has definitive knowledge about the types present in the program, including generic instantiations, which is what allows ILC to compile the program. You cannot introduce new types at runtime when using NativeAOT, and all callsites and reflected upon members are either statically known or brought in by one or another form of annotation. This is not related to JIT because the only difference in generic handling is when the compilation takes place. It is handled by the same compiler back-end being fed the same information. In fact, this also applies to trimming with JIT publish modes. Generics themselves are only tangentially related to reachability analysis. You are misunderstanding the way this works, this isn't Unity's Mono.
Putting in more practical terms - had NativeAOT not supported List<T> where T is an open generic, most hello-world scenarios would not work at all. And yet, somehow, by divine intervention, ASP.NET Core, DapperAOT, Avalonia, Uno as well as MAUI iOS under Simulator, even damn WinForms that was never made with NAOT in mind (with a helper package), and so on and so forth - all complex applications, work under NativeAOT.
neonsunset|1 year ago
Putting in more practical terms - had NativeAOT not supported List<T> where T is an open generic, most hello-world scenarios would not work at all. And yet, somehow, by divine intervention, ASP.NET Core, DapperAOT, Avalonia, Uno as well as MAUI iOS under Simulator, even damn WinForms that was never made with NAOT in mind (with a helper package), and so on and so forth - all complex applications, work under NativeAOT.