Correctly perform analysis for compiler-generated methods

[agocke]

This a blanket issue for analyzing compiler generated code, like async/iterator state machines and nested functions (lambdas, local functions).

The first task is to design the expected user behavior. For instance, if you call a method annotated with RequiresUnreferencedCode in a local function, does placing RequiresUnreferencedCode on the containing method suppress the warning? Or do you need to place RequiresUnreferencedCode on the local function? The C# compiler is somewhat inconsistent about requirements here -- if you place unsafe on a method, the local function is considered unsafe as well. However, if you use await in a local function, making the parent method async is not sufficient; the local function must also be declared async.

It's up to us to decide the expected user experience.

For data flow analysis, we need to decide if the user experience should be closer to the source code representation, or to the behavior between methods. The linker doesn't normally do interprocedural analysis, and neither does the C# compiler, but for local functions C# does do interprocedural flow analysis for definite assignment. If we want the experience of captured variables to be closer to the experience of local variables, we likely need to do interprocedural analysis. If we think the experience of fields is sufficient, then we don't.

Once we decide on a user experience then need to examine technical requirements: do we think that attributes can be propagated automatically? Or do we want to try to rebuild some of the knowledge of source code from the IL? If we do need to rebuild some knowledge of source code, is there something we need or want from the C# compiler?

We also need to plan what's necessary for 6.0 vs later. We may want a short and long term solution.

[marek-safar]

Please keep in mind that the linker is not the C# compiler post analyzer but a generic IL linking/trimming tool. The same experience should be available to developers writing F# code.

[agocke]

Sure -- once we decide on the user experience we can design a technical solution which will hopefully be implementable by both the C# and F# compilers. Of course, support for any particular language will be dependent on the language's compiler implementing the feature.

[MichalStrehovsky]

The .NET Native analyzer hardcoded the shape of e.g. async state machines and was able to propagate dataflow through that. Given .NET Native is where the dataflow analysis originated, we could very cheaply steal that. I intentionally didn't port that part over because I pretty strongly think we should not do that. But it's temptingly cheap, so calling this out.

[vitek-karas]

#2075 implements support for warning suppression via UnconditionalSuppressMessage or RequiresUnreferencedCode on iterator and async method bodies.