-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Fix missed places in dataflow analysis that introduce genericness #118020
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes missed cases in dataflow analysis that were failing to properly track and validate generic parameter access patterns. The changes ensure that when types with generic constraints are accessed through various IL operations (boxing, array creation, etc.), the dataflow analysis correctly validates that the generic type arguments satisfy the declared constraints.
Key changes:
- Extends dataflow analysis to cover boxing operations,
mkrefany
,ldtoken
, and array creation - Adds validation for instance methods on value types with generic constraints
- Includes comprehensive test cases for the newly covered scenarios
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
GenericParameterDataFlow.cs | Adds test cases for boxing, mkrefany, array operations, and instance methods on value types |
ILImporter.Scanner.cs | Adds dataflow dependency tracking for mkrefany, ldtoken, boxing, and array creation operations |
UsageBasedMetadataManager.cs | Implements new overload for tracking dependencies due to type access |
MetadataManager.cs | Adds virtual method for type access dependency tracking |
ReflectionMethodBodyScanner.cs | Adds type-based access validation and extends validation to value type instance methods |
MethodBodyScanner.cs | Extends IL scanning to handle box and mkrefany operations with proper type token access |
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I right in thinking that these are the same cases we would need to detect for #90115?
Unexpected warning found: ILLink: Trim analysis warning IL2091: Mono.Linker.Tests.Cases.DataFlow.GenericParameterDataFlow.TestInArray<T>(): 'T' generic argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor' in 'Mono.Linker.Tests.Cases.DataFlow.GenericParameterDataFlow.RequiresParameterlessCtor<T>'. The generic parameter 'T' of 'Mono.Linker.Tests.Cases.DataFlow.GenericParameterDataFlow.TestInArray<T>()' does not have matching annotations. The source value must declare at least the same requirements as those declared on the target location it is assigned to.
Possibly, but I haven't put much thought into it from that angle. |
Resolves #117998.
Fixes the cases in the bug and adds a couple more obscure corner cases.
Cc @dotnet/ilc-contrib