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

Warn on method access in Requires analyzers #110086

Merged
merged 8 commits into from
Dec 31, 2024

Conversation

jtschuster
Copy link
Member

The issue with calling Methods with requires is the the method itself, not the parameters. Warning on the entire invocation including the parameters can be confusing. Instead, we should warn just on the method access for Requires. DynamicallyAccessedMembers should still warn on the invocation.

Fixes #109823.

The issue with calling Methods with requires is the the method itself,
not the parameters. Warning on the entire invocation including the
parameters can be confusing. Instead, we should warn just on the method
access for Requires. DynamicallyAccessedMembers should still warn on the
invocation.
@dotnet-issue-labeler dotnet-issue-labeler bot added the area-Tools-ILLink .NET linker development as well as trimming analyzers label Nov 22, 2024
@dotnet-policy-service dotnet-policy-service bot added the linkable-framework Issues associated with delivering a linker friendly framework label Nov 22, 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.

The fix LGTM but looks like there are some failures.

Not for this PR, but I'm wondering if it would be better for the DAM analyzer to warn on the specific parameter with a DAM mismatch, instead of the entire invocation.

@jtschuster
Copy link
Member Author

It looks like this is causing new warnings because of interceptors. The methods in source cause warnings, but are intercepted to other methods that don't have warnings, and Roslyn must silence the existing warning. Changing the location to not include the entire call site must mess with the silencing.

@jtschuster
Copy link
Member Author

The previous failures were due to the Microsoft.Extensions.Configuration diagnostic suppressors. I've updated those to check MemberAccessExpressions in addition to the InvocationExpression as potential sources of IL2026.

@sbomer sbomer requested a review from a team December 11, 2024 18:38
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.

LGTM otherwise. Thanks!

@jtschuster jtschuster merged commit 511d266 into dotnet:main Dec 31, 2024
105 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Jan 31, 2025
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.

Location (highlighting) of IL2026 diagnostic could be improved
3 participants