Fix local function called from method and state machine (#2722)

* Add tests for nested functions called from nested state machines

The existing algorithm to recursively discover calls to local functions
from a user method was incorrect for the case where a local function
was called from a state machine local function's MoveNext method.
These methods were being treated as roots for the discovery, as if they
were user code, which caused a failure downstream when we assumed that
each local function belongs to a unique user method - since a local function
might be called from a user method _and_ a nested state machine local function.

The existing behavior also had the issue that a local function state machine's
attributes could suppress warnings from nested local functions, going against the
behavior for normal nested functions in the linker.

* Don't fail on multiple user methods for same nested function

* Correctly handle iterator local functions calling nested functions

This fixes the issues shown in the tests by letting the state machine
types participate in the call graph discovery instead of being considered
as roots. Now any local functions called from state machine local functions
will be associated with the user method, not with the state machine MoveNext
method.

* Fix test for analyzer

* Update src/linker/Linker/CompilerGeneratedState.cs

Co-authored-by: Vitek Karas <10670590+vitek-karas@users.noreply.github.com>

* Adjust comments and docs

* Fix docs

Co-authored-by: Vitek Karas <10670590+vitek-karas@users.noreply.github.com>

1 files changed, 31 insertions, 0 deletions

diff --git a/docs/error-codes.md b/docs/error-codes.md
index 1632f22ad..c775fbbd0 100644
--- a/docs/error-codes.md
+++ b/docs/error-codes.md
@@ -1827,6 +1827,37 @@ void TestMethod()
   }
   ```
 
+#### `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.
+
+- Trimmer currently can't correctly handle if the same compiler generated lambda or local function is associated with two different methods. We don't know of any C# patterns which would cause this problem, but it is possible to write code like this in IL.
+
+  Only a meta-sample:
+
+  ```C#
+  [RequiresUnreferencedCode ("")] // This should suppress all warnings from the method
+  void UserDefinedMethod()
+  {
+      // Uses the compiler-generated local function method
+      // The IL2026 from the local function should be suppressed in this case
+  }
+
+  // IL2107: Methods 'UserDefinedMethod' and 'SecondUserDefinedMethod' are both associated with state machine type '<compiler_generated_state_machine>_type'.
+  [RequiresUnreferencedCode ("")] // This should suppress all warnings from the method
+  void SecondUserDefinedMethod()
+  {
+      // Uses the compiler-generated local function method
+      // The IL2026 from the local function should be suppressed in this case
+  }
+
+  internal static void <UserDefinedMethod>g__LocalFunction|0_0()
+  {
+      // Compiler-generated method emitted for a local function.
+      // This should only ever be called from one user-defined method.
+  }
+
+  ```
+
+
 ## Single-File Warning Codes
 
 #### `IL3000`: 'member' always returns an empty string for assemblies embedded in a single-file app. If the path to the app directory is needed, consider calling 'System.AppContext.BaseDirectory'