-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Don't keep members of pointer or byref element types #106215
Conversation
@@ -58,39 +58,32 @@ internal void MarkTypeForDynamicallyAccessedMembers (in MessageOrigin origin, Ty | |||
|
|||
// Resolve a (potentially assembly qualified) type name based on the current context (taken from DiagnosticContext) and mark the type for reflection. | |||
// This method will probe the current context assembly and if that fails CoreLib for the specified type. Emulates behavior of Type.GetType. | |||
internal bool TryResolveTypeNameAndMark (string typeName, in DiagnosticContext diagnosticContext, bool needsAssemblyName, [NotNullWhen (true)] out TypeDefinition? type) | |||
internal bool TryResolveTypeNameAndMark (string typeName, in DiagnosticContext diagnosticContext, bool needsAssemblyName, [NotNullWhen (true)] out TypeReference? type) |
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.
With the change to ResolveToTypeDefinition, TryResolveTypeNameAndMark now gives back a TypeReference representing the pointer/byref type. MarkTypeVisibleToReflection will go through MarkType that marks the underlying element type, but the call to MarkTypeForDynamicallyAccessedMembers from RequireDynamicallyAccessedMembersAction won't mark any of its members (because it resolves the pointer/byref to null via ResolveToTypeDefinition first).
- Add doc comment
The equality check needs to determine whether two TypeProxy instances represent the same type. The check was incorrect when two different object instances were allocated to represent the same generic instantiated type. ILCompiler doesn't have this problem because it uses a cache to ensure that the same object instance represents a given instantiated generic type. Discovered while investigating #106215, see more context at #106215 (comment). The new testcase also uncovered an issue in the analyzer that was fixed in #106909.
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.
Thank you!
/ba-g "unrelated timeout" |
Partial fix for one of the cases mentioned in dotnet#106886. This moves some of the tests to ObjectGetTypeDataflow.cs because ObjectGetType.cs is skipped by native AOT. Fixes an issue discovered while investigating dotnet#106215.
The equality check needs to determine whether two TypeProxy instances represent the same type. The check was incorrect when two different object instances were allocated to represent the same generic instantiated type. ILCompiler doesn't have this problem because it uses a cache to ensure that the same object instance represents a given instantiated generic type. Discovered while investigating dotnet#106215, see more context at dotnet#106215 (comment). The new testcase also uncovered an issue in the analyzer that was fixed in dotnet#106909.
Fixes the following warnings in ILLink: ```csharp var type = Type.GetType ("ElementType&, test"); RequireConstructor(type); // IL2026 [RequiresUnreferencedCode("ElementType")] class ElementType {} static void RequireConstructor([DynamicallyAccessedMembers (DynamicallyAccessedMemberTypes.PublicParameterlessConstructor)] Type type) { } ``` This warns for reflection access to the ElementType constructor, even though the byref type has no constructor. NativeAot doesn't produce this warning.
Fixes #106214