Fix trim analyzer warning for inferred type arguments

[sbomer]

Fixes #86032.

This replaces the syntax-based logic with:

• ISymbol-based logic that looks at generic instantiations in parameter types, return types, and base/interface types
• IOperation-based logic that looks at invocations

The syntax-based logic used to also warn for the types of local variables, but SymbolKind.Local isn't supported for RegisterSymbolAction. Since this falls into the category of warnings that isn't strictly necessary (based on nativeaot logic which only warns on generic instantiations that can actually lead to code execution), I just left out local variables.

I'm slightly concerned that this could be missing some cases, but at least it works on our existing testcases.

There are two slight differences in warning locations, which I don't expect to cause issues for warning suppressions:

• For invocations, the warning location used to be the generic method name, without the argument list. Using the IOperation-based approach, we use the invocation's location that includes the argument list.
• For properties that use arrow syntax (RequireMethods<TFields> Property => null), the ISymbol-based approach warns on the underlying getter method, whose location seems to be the body of the accessor. We used to warn on the return type specifically, but I couldn't find a better way to get the location.

[ghost]

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

Issue Details

---

Fixes #86032.

This replaces the syntax-based logic with:

• ISymbol-based logic that looks at generic instantiations in parameter types, return types, and base/interface types
• IOperation-based logic that looks at invocations

The syntax-based logic used to also warn for the types of local variables, but SymbolKind.Local isn't supported for RegisterSymbolAction. Since this falls into the category of warnings that isn't strictly necessary (based on nativeaot logic which only warns on generic instantiations that can actually lead to code execution), I just left out local variables.

I'm slightly concerned that this could be missing some cases, but at least it works on our existing testcases.

There are two slight differences in warning locations, which I don't expect to cause issues for warning suppressions:

• For invocations, the warning location used to be the generic method name, without the argument list. Using the IOperation-based approach, we use the invocation's location that includes the argument list.
• For properties that use arrow syntax (RequireMethods<TFields> Property => null), the ISymbol-based approach warns on the underlying getter method, whose location seems to be the body of the accessor. We used to warn on the return type specifically, but I couldn't find a better way to get the location.

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

[vitek-karas]

In general looks good.