Fix type parameter mapping logic in ILLink/ILCompiler

[sbomer]

The compiler-generated code for Container<T> in this testcase contains two closure types, one for each lambda in the expression (Func<T, T> x) => v => x(x(v));. The outer closure environment type is instantiated by its cctor, which stores an instance into a static field. It is never directly instantiated from another type - instead, the cctor is triggered when the cctor of Container<T> access this static field.

This case was missing from the compiler-generated type parameter mapping logic. We need to discover the substituted generic typeref for the outer closure environment from the ldsfld.

Fixes #91880.

[ghost]

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

Issue Details

---

The compiler-generated code for Container<T> in this testcase contains two closure types, one for each lambda in the expression (Func<T, T> x) => v => x(x(v));. The outer closure environment type is instantiated by its cctor, which stores an instance into a static field. It is never directly instantiated from another type - instead, the cctor is triggered when the cctor of Container<T> access this static field.

This case was missing from the compiler-generated type parameter mapping logic. We need to discover the substituted generic typeref for the outer closure environment from the ldsfld.

Fixes #91880.

Author:	sbomer
Assignees:	sbomer
Labels:	area-Tools-ILLink
Milestone:	-

[agocke]

LGTM, I didn't anticipate that we could have only a ldsfld to the target, and no stsfld from the outside. But it looks like that's the case, so we need to track both loads and stores.

[sbomer]

/backport to release/8.0

[github-actions]

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6201152053