Handle MakeGeneric APIs in dataflow

[MichalStrehovsky]

Contributes to #81204.

With this, we can handle typeof(Foo<>).MakeGenericType(typeof(T)) (and MakeGenericMethod), including in shared generic code.

The dataflow analysis change should be straightforward (we just look if it's a known array, with all known elements). I scoped this down to "exactly one array" and "exactly one possible value in the element" because the objective is constraint bridging code. We could extend to supporting multiple values, but I don't see a need.

If we know what the values are, we elide generating a warning.

The support for this in the rest of the compiler is a bit annoying due to generics. We only run dataflow on uninstantiated code. So we have a dependency node representing the dataflow analysis. This node obviously cannot know what are all the possible instantiations we saw, so it cannot directly report things about instantiated generic code. Three possible options to solve this:

• Re-run dataflow analysis on instantiated code. I didn't feel great about doing that.
• Introduce a new node SpecializedDataflowAnalyzedMethodNode that would be injected as a conditional dependency of all scanned/compiled method bodies, conditioned on DataflowAnalyzedMethodNode being present. This would work, but to obtain a DataflowAnalyzedMethod we need the MethodIL of the definition (not the MethodDesc) and that started to look sketchy.
• Use dynamic dependencies. We only use these for GVM analysis right now. They give a node the ability to receive callbacks when new nodes are added to the graph. These nodes need to declare they are "interesting" to dynamic dependency analysis. It's not great, but it works.

I went with option 3.

I'm not making this resolve the above issue. We'd ideally want to implement this in the analyzer too. I had a quick look at that and it looks like we need to write a brand new DiagnosticAnalyzer similar to the DynamicallyAccessedMembersAnalyzer.

Cc @dotnet/ilc-contrib

[ghost]

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

Issue Details

---

Contributes to #81204.

With this, we can handle typeof(Foo<>).MakeGenericType(typeof(T)) (and MakeGenericMethod), including in shared generic code.

The dataflow analysis change should be straightforward (we just look if it's a known array, with all known elements). I scoped this down to "exactly one array" and "exactly one possible value in the element" because the objective is constraint bridging code. We could extend to supporting multiple values, but I don't see a need.

If we know what the values are, we elide generating a warning.

The support for this in the rest of the compiler is a bit annoying due to generics. We only run dataflow on uninstantiated code. So we have a dependency node representing the dataflow analysis. This node obviously cannot know what are all the possible instantiations we saw, so it cannot directly report things about instantiated generic code. Three possible options to solve this:

• Re-run dataflow analysis on instantiated code. I didn't feel great about doing that.
• Introduce a new node SpecializedDataflowAnalyzedMethodNode that would be injected as a conditional dependency of all scanned/compiled method bodies, conditioned on DataflowAnalyzedMethodNode being present. This would work, but to obtain a DataflowAnalyzedMethod we need the MethodIL of the definition (not the MethodDesc) and that started to look sketchy.
• Use dynamic dependencies. We only use these for GVM analysis right now. They give a node the ability to receive callbacks when new nodes are added to the graph. These nodes need to declare they are "interesting" to dynamic dependency analysis. It's not great, but it works.

I went with option 3.

I'm not making this resolve the above issue. We'd ideally want to implement this in the analyzer too. I had a quick look at that and it looks like we need to write a brand new DiagnosticAnalyzer similar to the DynamicallyAccessedMembersAnalyzer.

Cc @dotnet/ilc-contrib

Author:	MichalStrehovsky
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[MichalStrehovsky]

@yowl @SingleAccretion this will need a matching change in nativeAOT-LLVM - just match the one-line diff in ScannedMethodNode/MethodCodeNode in the node that represents compiled method bodies.

The failure mode you'll see without the matching change is runtime failure in the new tests that do MakeGenericType/Method.

If you wanted to, you could just proactively make the change now, I don't think it'll hurt anything.