Would it be possible to opt-in to flow analysis between methods for more accurate trimming. (specifically around native AOT)

[Beau-Gosse-dev]

In reference to this quote from the below page:

For performance and stability, flow analysis isn't performed between methods, so an annotation is needed to pass information between methods, from the reflection call (GetMethods) to the source of the Type.

https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/fixing-warnings

What stability problems come from flow analysis between methods? If it's just a performance concern, can we leave it up to the user if they want their trimming to be slower but have better results?

[vitek-karas]

can we leave it up to the user if they want their trimming to be slower but have better results?

What do you have in mind with "better results"?

Cross method analysis would very likely not decrease the size of the app in meaningful way (actually quite the opposite).

What it could do in theory is make it possible to correctly trim code which is not fully annotated. But from our own experience annotating libraries, it is rare that just adding annotations is enough to make a library fully trim compatible. Typically, existing libraries have patterns which the trimmer doesn't understand and so it's either necessary to slightly change the code or otherwise hint the trimmer. Even cross-method analysis would need to raise warnings in these cases. The places where it might help are the cases where one needs to mechanically propagate annotations through the code.

Note: warnings are probably the hardest part about the cross-method analysis, since it's hard to "blame" the right spot in the code, or provide enough information to the user to find the right spot. If you have experience with C++ templates, see what kinds of errors C++ compilers produce where there is a problem with the templates... it's really complex - fundamentally the cross-method analysis is a similar problem to that. Another example is reference types in C# - the ? mechanics. The language team also decided to effectively scope the auto-propagate to a single method.

The tools already perform a very limited cross method analysis - if you have compiler generated code (iterators, async methods, local functions, ...) the tools need to be able to propagate the annotations without the help of attributes. This is already a rather complex part of the tooling. It's fortunately simplified by the fact that the tools can get by with only certain patterns being supported as the compiler only generates those.

I think it would make sense to eventually expand the supported patterns, for example what might be interesting is to automatically flow annotations across private methods, assuming the UX problem with warnings as mentioned above doesn't get out of hand. (The idea is that private methods are within a single class and thus it's easier for developers to reason about them as a single unit).

Ultimately, the benefits we see in cross method analysis are not big enough yet to justify the cost of implementing it.