Skip to content
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

Merged
merged 9 commits into from
Aug 29, 2024

Conversation

sbomer
Copy link
Member

@sbomer sbomer commented Aug 9, 2024

Fixes #106214

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-Tools-ILLink .NET linker development as well as trimming analyzers label Aug 9, 2024
@dotnet-policy-service dotnet-policy-service bot added the linkable-framework Issues associated with delivering a linker friendly framework label Aug 9, 2024
@sbomer sbomer requested a review from a team August 20, 2024 17:33
@sbomer sbomer marked this pull request as ready for review August 20, 2024 17:33
@@ -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)
Copy link
Member Author

@sbomer sbomer Aug 20, 2024

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
sbomer added a commit that referenced this pull request Aug 27, 2024
Partial fix for one of the cases mentioned in
#106886.

This moves some of the tests to ObjectGetTypeDataflow.cs because
ObjectGetType.cs is skipped by native AOT. Fixes an issue discovered
while investigating #106215.
sbomer added a commit that referenced this pull request Aug 28, 2024
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.
Copy link
Member

@jtschuster jtschuster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@sbomer
Copy link
Member Author

sbomer commented Aug 29, 2024

/ba-g "unrelated timeout"

@sbomer sbomer merged commit 2694613 into dotnet:main Aug 29, 2024
75 of 77 checks passed
jtschuster pushed a commit to jtschuster/runtime that referenced this pull request Sep 17, 2024
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.
jtschuster pushed a commit to jtschuster/runtime that referenced this pull request Sep 17, 2024
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.
jtschuster pushed a commit to jtschuster/runtime that referenced this pull request Sep 17, 2024
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.
@github-actions github-actions bot locked and limited conversation to collaborators Oct 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Tools-ILLink .NET linker development as well as trimming analyzers linkable-framework Issues associated with delivering a linker friendly framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ILLink keeps members of pointer/byref types for DynamicallyAccessedMembers
2 participants