Don't keep members of pointer or byref element types #106215
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dotnet-issue-labeler
bot
added
the
area-Tools-ILLink
dotnet-policy-service
bot
added
the
linkable-framework
sbomer
commented
Aug 20, 2024
sbomer
commented
Aug 20, 2024
| @@ -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.
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).
jtschuster
reviewed
Aug 21, 2024
This was referenced Aug 23, 2024
- Add doc comment
Open
3 tasks
sbomer
added a commit
that referenced
this pull request
Aug 27, 2024
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.
|
/ba-g "unrelated timeout" |
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #106214