In dotnet land generics are JITted on demand at runtime when you first execute a specific instance of that generic type.
So List<int> doesn't necessarily get JItted even though List<long> has been. This poses a bit of a problem for AOT compilation.
You would essentially have to either
A) Trace all possible execution paths and determine every needed generic instantiation and precompile and ship them all. This ain't easy, and it might be impossible. Also expect massive binaries due to all those types.
Note that since Windows 8, .NET Store apps are fully AOT to native code, there is no JIT.
Window 8.x used the cloud compiler with MDIL deployments (based on Bartok MDIL from Singularity), doing on-device linking.
Windows 10 makes use of .NET Native toolchain.
The only restriction is reflection, all classes that are accessed via reflection need to be explicitly mentioned on a rd.xml file, otherwise the linker might prune them.
It does, if the AOT compiler is advanced enough to examine all code and determine that `int` is a possible type being used with List<T>. Mono has had a lot of advancements on these techniques over the years, as it's the only way for them to let Xamarin devs deploy apps on the iPhone.
In regular .NET you can instantiate generic types with a type parameter provided at runtime.
Of course it's not something you should ever do in regular code, but it can be useful for deserialization and stuff like that, so you can create e.g. a list of arbitrary types received over the wire.
Does the AOT compiler just crash if asked to compile a project that uses reflection?
So List<int> doesn't necessarily get JItted even though List<long> has been. This poses a bit of a problem for AOT compilation.
You would essentially have to either
A) Trace all possible execution paths and determine every needed generic instantiation and precompile and ship them all. This ain't easy, and it might be impossible. Also expect massive binaries due to all those types.
B) Bundle a JIT and lazily emit code as needed.
C) No generics?