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

Support Type.GetMember usage analysis properly with IL3050 warning (NAOT) #94745

Open
hamarb123 opened this issue Nov 15, 2023 · 9 comments
Open
Labels
area-Tools-ILLink .NET linker development as well as trimming analyzers in-pr There is an active PR which will close this issue when it is merged
Milestone

Comments

@hamarb123
Copy link
Contributor

hamarb123 commented Nov 15, 2023

Description

Using the Type.GetMember function gives warnings that are not necessary when AOT analysis is enabled.

Reproduction Steps

Enable AOT compatible analysis: <IsAotCompatible>true</IsAotCompatible>.
Write code like so:

void X(Type t)
{
    t.GetMember("SomeMethod", MemberTypes.Method, BindingFlags.Public | BindingFlags.Static | BindingFlags.NonPublic);
}

Expected behavior

All that should be necessary to appease the analyser is:

[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicMethods | DynamicallyAccessedMemberTypes.NonPublicMethods)]

Actual behavior

Instead I get the following:
image

Regression?

No response

Known Workarounds

Ignore the warning.

Configuration

.NET SDK 8.0.0
VS 17.8.0
Windows 10.0.19045 x64
I don't see why it would be specific to this configuration

Other information

This was likely just overlooked when implementing the analyser. I've only discovered it now since I'm only now adding AOT support.

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Nov 15, 2023
@ghost
Copy link

ghost commented Nov 15, 2023

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

Using the Type.GetMember function gives warnings that are not necessary when AOT analysis is enabled.

Reproduction Steps

Enable AOT compatible analysis: <IsAotCompatible>true</IsAotCompatible>.
Write code like so:

type.GetMember("SomeMethod", MemberTypes.Method, BindingFlags.Public | BindingFlags.Static | BindingFlags.NonPublic);

Expected behavior

All that should be necessary to appease the analyser is:

[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicMethods | DynamicallyAccessedMemberTypes.NonPublicMethods)]

Actual behavior

Instead I get the following:
image

Regression?

No response

Known Workarounds

Ignore the warning.

Configuration

.NET SDK 8.0.0
VS 17.8.0
Windows 10.0.19045 x64
I don't see why it would be specific to this configuration

Other information

This was likely just looked over when implementing the analyser. I've only discovered it now since I'm only now adding AOT support.

Author: hamarb123
Assignees: -
Labels:

untriaged, area-NativeAOT-coreclr

Milestone: -

@hamarb123
Copy link
Contributor Author

hamarb123 commented Nov 15, 2023

I'd be happy to make a PR to fix this btw - if someone could point me to the code for this analyser, and people are happy for me to do it.

@agocke
Copy link
Member

agocke commented Nov 15, 2023

I think you're confusing GetMethod with GetMember. You're correct that GetMethod only requires PublicMethods and PrivateMethods, but GetMember requires DynamicallyAccessedMemberTypes.PublicConstructors | DynamicallyAccessedMemberTypes.NonPublicConstructors | DynamicallyAccessedMemberTypes.PublicMethods | DynamicallyAccessedMemberTypes.NonPublicMethods | DynamicallyAccessedMemberTypes.PublicFields | DynamicallyAccessedMemberTypes.NonPublicFields | DynamicallyAccessedMemberTypes.PublicNestedTypes | DynamicallyAccessedMemberTypes.NonPublicNestedTypes | DynamicallyAccessedMemberTypes.PublicProperties | DynamicallyAccessedMemberTypes.NonPublicProperties | DynamicallyAccessedMemberTypes.PublicEvents | DynamicallyAccessedMemberTypes.NonPublicEvents

@hamarb123
Copy link
Contributor Author

hamarb123 commented Nov 15, 2023

@agocke no I'm not, I specified MemberTypes.Method in the code, therefore I don't see why I'd need anything other than methods.

@MichalStrehovsky
Copy link
Member

We'd need to extend intrinsic handling of this method in the Roslyn analyzer and in ILLinker/NativeAOT compiler. Searching the codebase for Type_GetMember should get you close enough. Looks like we already look at BindingFlags but that doesn't help much.

Known Workarounds

Ignore the warning.

The warning should be suppressible and this might be safe to suppress (unless there's some obscure corner case behavior difference between GetMember(MemberTypes.Method) and GetMethod, which we'd need to investigate when the intrinsic is introduced).

@MichalStrehovsky MichalStrehovsky added area-Tools-ILLink .NET linker development as well as trimming analyzers and removed area-NativeAOT-coreclr labels Nov 15, 2023
@ghost
Copy link

ghost commented Nov 15, 2023

Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

Using the Type.GetMember function gives warnings that are not necessary when AOT analysis is enabled.

Reproduction Steps

Enable AOT compatible analysis: <IsAotCompatible>true</IsAotCompatible>.
Write code like so:

void X(Type t)
{
    t.GetMember("SomeMethod", MemberTypes.Method, BindingFlags.Public | BindingFlags.Static | BindingFlags.NonPublic);
}

Expected behavior

All that should be necessary to appease the analyser is:

[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicMethods | DynamicallyAccessedMemberTypes.NonPublicMethods)]

Actual behavior

Instead I get the following:
image

Regression?

No response

Known Workarounds

Ignore the warning.

Configuration

.NET SDK 8.0.0
VS 17.8.0
Windows 10.0.19045 x64
I don't see why it would be specific to this configuration

Other information

This was likely just overlooked when implementing the analyser. I've only discovered it now since I'm only now adding AOT support.

Author: hamarb123
Assignees: -
Labels:

untriaged, area-Tools-ILLink

Milestone: -

@vitek-karas
Copy link
Member

The fix would be here:

bindingFlags = GetBindingFlagsFromValue (argumentValues[2]);

The value of the new enum should already be tracked as an integer by dataflow, so I don't think it would need changes to the dataflow itself.

Note that this code is shared by all 3 tools (ILLink, ILCompiler, the analyzer). Would need some more logic to figure out the correct member type masks but probably not too difficult.

Technically we can do even better and basically map this onto the handling of GetMethod - which has the ability to preserve only a single method, if the name of the method is a constant. But that's maybe a next level optimization on top.

I agree with Michal that we should investigate if there are behavioral differences between GetMember(.. Methods ...) and GetMethod().

@agocke
Copy link
Member

agocke commented Nov 15, 2023

Yup, my mistake, missed the binding flags. It would be cool to support this properly

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Nov 16, 2023
@hamarb123
Copy link
Contributor Author

I agree with Michal that we should investigate if there are behavioral differences between GetMember(.. Methods ...) and GetMethod().

Both GetMember and GetMethod begin to share the same implementation by this point.

return Query<MethodInfo>(MethodPolicies.Instance, name, bindingAttr).Disambiguate();

queryResult = Query<M>(policies, optionalName, bindingAttr, optionalPredicate);

The only differences I see up to this point is that GetMember allows a pattern with * at the end to specify anything starting with the prior characters (e.g., abc* means anything starting with abc). That seems to be the only difference to me.

@agocke agocke added this to AppModel Nov 28, 2023
@agocke agocke added this to the Future milestone Apr 15, 2024
@sbomer sbomer removed the untriaged New issue has not been triaged by the area owner label Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Tools-ILLink .NET linker development as well as trimming analyzers in-pr There is an active PR which will close this issue when it is merged
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

5 participants