Non-actionable warnings about compiler-generated code

[sbomer]

We produce the following warnings when the same compiler-generated code is associated with multiple user methods:

• IL2107: Trim analysis: Methods 'method1' and 'method2' are both associated with state machine type 'type'. This is currently unsupported and may lead to incorrectly reported warnings.
• IL2117: Trim analysis: Methods 'method1' and 'method2' are both associated with lambda or local function 'method'. This is currently unsupported and may lead to incorrectly reported warnings.

@vitek-karas pointed out these aren't really actionable. From #2722 (comment):

We need a bit more actionable message - or something like that. If we think this can actually happen. If we don't think it can happen we should probably throw.
As is the warning is unactionable by the user. Especially since it requires knowledge of Roslyn implementation details to even understand what it's saying.
If we think this can happen, we should add enough logic to only issue the warning if we actually need information from it - meaning that we would probably need to look at RUC and Suppress attributes on the involved methods and if none are present, we would simply not warn. And if there are some we would warn saying something like "Please don't use RUC on this method" or something along those lines.

So the question is what's better to do if we encounter an unexpected pattern in compiler-generated code - should we throw, or produce a diagnostic? And if we produce a diagnostic, what information should it include?