Fix stack overflow in compiler-generated state #109207
Conversation
dotnet-issue-labeler
bot
added
the
area-Tools-ILLink
dotnet-policy-service
bot
added
the
linkable-framework
|
Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas |
| @@ -122,7 +122,7 @@ public static bool TryGetStateMachineType (MethodDefinition method, [NotNullWhen | |||
| return null; | |||
|
|
|||
| // Avoid repeat scans of the same type | |||
| if (_cachedTypeToCompilerGeneratedMembers.ContainsKey (type)) | |||
| if (!_cachedTypeToCompilerGeneratedMembers.TryAdd (type, null)) | |||
| return type; | |||
There was a problem hiding this comment.
Just to clarify (might be worth a comment): If we ever get into the recursive call situation, this effectively ignores anything in the compiler generate type (as if it's empty) -> for example suppressions would not work.
I think it's perfectly OK as a behavior, but might be worth a comment to make it clear it was an intentional behavioral choice.
There was a problem hiding this comment.
Made a fix that avoids the recursive call, so this is no longer the case.
|
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
|
@sbomer This fixed work. Will you be able to land this? |
Delay processing of warnings from building compiler-generated type info
When building the compiler-generated type info for a type, there are some cases that produce warnings due to unexpected IL. This can recurse back into the compiler-generated type info logic when checking for warning suppressions, leading to stack overflow.
This fixes the issue by delaying the logging of warnings until after the compiler-generated type info has been fully built for a given type.
Fixes #109157