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 emit analyzer warnings for MakeGeneric understood by ILC #100858

Merged
merged 2 commits into from
Apr 12, 2024

Conversation

MichalStrehovsky
Copy link
Member

Follow up to #99037.
Resolves #81204.

When MakeGenericXXX API is used in the "bridging constraints" pattern and all types/members involved are statically known, don't emit warning from the Roslyn analyzer since ILC will do the right thing and ensure this works.

Cc @dotnet/ilc-contrib

Follow up to dotnet#99037.
Resolves dotnet#81204.

When `MakeGenericXXX` API is used in the "bridging constraints" pattern and all types/members involved are statically known, don't emit warning from the Roslyn analyzer since ILC will do the right thing and ensure this works.
@MichalStrehovsky MichalStrehovsky requested a review from sbomer April 10, 2024 09:16
@dotnet-issue-labeler dotnet-issue-labeler bot added the area-Tools-ILLink .NET linker development as well as trimming analyzers label Apr 10, 2024
@dotnet-policy-service dotnet-policy-service bot added the linkable-framework Issues associated with delivering a linker friendly framework label Apr 10, 2024
Copy link
Member

@sbomer sbomer left a comment

Choose a reason for hiding this comment

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

Did you think about sharing some of these tests between ILC and the analyzer?

if (!instance.IsEmpty ()) {
foreach (var value in instance.AsEnumerable ()) {
if (value is SystemTypeValue) {
if (!IsKnownInstantiation (arguments[0])) {
Copy link
Member

Choose a reason for hiding this comment

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

Should this also check that the instantiation length matches the method?

Copy link
Member Author

Choose a reason for hiding this comment

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

If the instantiation length doesn't match, we'd get an exception at runtime both before and after AOT compilation, so maybe we don't need an AOT warning. The code is wrong, but we don't concern ourselves with bugs that exist before and after publish.

Copy link
Member

Choose a reason for hiding this comment

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

So should this return true if it's not a known instantiation, but the length doesn't match? I think that's what ILC does if I read #99037 correctly.

Copy link
Member

Choose a reason for hiding this comment

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

Oh never mind, it triggers the warning if TryGetMakeGenericInstantiation returns false. Probably not an important edge case anyway.

@MichalStrehovsky
Copy link
Member Author

Did you think about sharing some of these tests between ILC and the analyzer?

Do we have a good spot for that? For the AOT testing, there's more concern about whether it actually works at runtime, so I wrote tests that actually execute. We don't typically execute the code in illink/analyzer testing.

@sbomer
Copy link
Member

sbomer commented Apr 11, 2024

https://github.com/dotnet/runtime/blob/main/src/tools/illink/test/Mono.Linker.Tests.Cases/DataFlow/MakeGenericDataFlow.cs might be a good place, except this suppresses IL3050 currently. You could fix up the ExpectedWarnings for AOT or add a new file next to that one. Just a suggestion, I think the current approach is OK too.

@MichalStrehovsky MichalStrehovsky merged commit 7b534da into dotnet:main Apr 12, 2024
80 checks passed
@MichalStrehovsky MichalStrehovsky deleted the fix81204 branch April 12, 2024 13:03
matouskozak pushed a commit to matouskozak/runtime that referenced this pull request Apr 30, 2024
…t#100858)

Follow up to dotnet#99037.
Resolves dotnet#81204.

When `MakeGenericXXX` API is used in the "bridging constraints" pattern and all types/members involved are statically known, don't emit warning from the Roslyn analyzer since ILC will do the right thing and ensure this works.
@github-actions github-actions bot locked and limited conversation to collaborators May 13, 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.

NativeAOT: Dependency analysis support for generic method reflection
2 participants