Skip to content

Conversation

@mrvoorhe
Copy link

@mrvoorhe mrvoorhe commented Jan 8, 2026

Merging into our branch since there hasn't been any engagement on the upstream PR jbevain#970

When importing a TypeSpecification, an element type or generic argument could be a TypeDefinition within the current module.
When this happens, a new TypeReference does not need to be created.  This can lead to a TypeReference being added to the typeref table for
a type that is already in the assembly.  This seems to hold together, although I don't think it's ideal.  And really my goal is to avoid failing this logic in the ILLink test framework https://github.com/dotnet/runtime/blob/cec44d6dff9de95421f199f65bbc80b8296da1c0/src/tools/illink/test/Mono.Linker.Tests/TestCasesRunner/ResultChecker.cs#L56

This fix superceeds jbevain#138.  I've left that fix in since that API is exposed publically and others could be depending on it.

While I was adjusting this logic, I thought I would apply the same logic to a TypeReference where the scope is the current modules assembly.
This case is a bit contrived as it shouldn't happen, but if it did, it would result in the same circular reference problem as jbevain#138
@mrvoorhe mrvoorhe merged commit 75df357 into burst-and-il2cpp-master Jan 8, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants