Trimming: Reflection access to compiler generated methods produces warnings

[vitek-karas]

Technically using reflection to access compiler generated methods could cause holes in trim analysis. This is because we don't analyze CG methods on their own, but only in the context of the user defined method which "owns" them. If they're invoked outside such context, the analysis may miss some incompatible behavior.

ILLink tried to mitigate this by producing warnings when we detect reflection access to CG method. Originally it produced warning always, but that was way too noisy. Modern C# produces lot of CG methods and using DAM annotations, it's really easy to accidentally "access" some of the CG methods "via reflection". So ILLink also implemented a heuristic, where it tried to detect if the method in question contains potentially dangerous code, this was done by looking for access to annotated members (mostly).

The end result of this is that ILLink can produce warnings IL2118, IL2119 and IL2120. These warnings are currently a "best effort" and there are cases where they don't need to be produced (overly aggressive heuristic in the ILLink). But there are also cases where they're not generated even though they should be (ILLink analysis doesn't catch everything in this case).

We considered implementing these in NativeAOT, but it proved to be problematic. The behavior of NativeAOT compiler is different enough, that the heuristic produces different results and there are cases were it produces warnings while ILLink doesn't. These places are also deep in internal structures of the NativeAOT runtime code, and suppressing these is problematic.

After a discussion we decided that we should not try to produce these warnings, and leave this as a known analysis hole. Reflection access to compiler generated methods is per C# "undefined behavior" and so it's already very problematic and should not be used. Combine this with trimming which will only make it slightly worse.

NativeAOT will not implement the necessary logic to produce IL2118, IL2119 and IL2120. We should probably remove these from ILLink eventually as well.

Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Technically using reflection to access compiler generated methods could cause holes in trim analysis. This is because we don't analyze CG methods on their own, but only in the context of the user defined method which "owns" them. If they're invoked outside such context, the analysis may miss some incompatible behavior.

ILLink tried to mitigate this by producing warnings when we detect reflection access to CG method. Originally it produced warning always, but that was way too noisy. Modern C# produces lot of CG methods and using DAM annotations, it's really easy to accidentally "access" some of the CG methods "via reflection". So ILLink also implemented a heuristic, where it tried to detect if the method in question contains potentially dangerous code, this was done by looking for access to annotated members (mostly).

The end result of this is that ILLink can produce warnings IL2118, IL2119 and IL2120. These warnings are currently a "best effort" and there are cases where they don't need to be produced (overly aggressive heuristic in the ILLink). But there are also cases where they're not generated even though they should be (ILLink analysis doesn't catch everything in this case).

We considered implementing these in NativeAOT, but it proved to be problematic. The behavior of NativeAOT compiler is different enough, that the heuristic produces different results and there are cases were it produces warnings while ILLink doesn't. These places are also deep in internal structures of the NativeAOT runtime code, and suppressing these is problematic.

After a discussion we decided that we should not try to produce these warnings, and leave this as a known analysis hole. Reflection access to compiler generated methods is per C# "undefined behavior" and so it's already very problematic and should not be used. Combine this with trimming which will only make it slightly worse.

NativeAOT will not implement the necessary logic to produce IL2118, IL2119 and IL2120. We should probably remove these from ILLink eventually as well.

Author:	vitek-karas
Assignees:	-
Labels:	area-Tools-ILLink
Milestone:	-