Detect generic cycles in the Roslyn analyzer

[MichalStrehovsky]

We currently have a gap that generic cycles will get reported by the AOT compiler when ran into, but the analyzer doesn't look for them.

In the general case, the cycle could form across multiple assemblies and a Roslyn analyzer will never see such cycle. In practice, whenever I saw such cycle, it was within a single assembly. So maybe we don't need perfect, a good enough is fine.

We should reuse the cycle detector from the AOT compiler. It was originally ported from .NET Native. I don't even know how it works, I just made it build and hooked it up: dotnet/runtimelab#1681 (notice first commit is just adding files from .NET Native and the next commit just replaces CCI with the managed type system).

[ghost]

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

Issue Details

---

We currently have a gap that generic cycles will get reported by the AOT compiler when ran into, but the analyzer doesn't look for them.

In the general case, the cycle could form across multiple assemblies and a Roslyn analyzer will never see such cycle. In practice, whenever I saw such cycle, it was within a single assembly. So maybe we don't need perfect, a good enough is fine.

We should reuse the cycle detector from the AOT compiler. It was originally ported from .NET Native. I don't even know how it works, I just made it build and hooked it up: dotnet/runtimelab#1681 (notice first commit is just adding files from .NET Native and the next commit just replaces CCI with the managed type system).

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