-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Unify trim warnings for accessing compiler generated code #86816
Conversation
Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas Issue DetailsThis modifies the behavior of both the illink and ilc to match and to implement some changes we've discussed recently - #86008. The semantic changes (mostly as compared to previous illink behavior):
Note that there are exceptions to the above rules, which can be described as: Accessing a token of a member in IL is considered a reflection access (because the token can be turned into a reflection object), but it is also considered a direct reference. So in that case marking is implemented as "reflection access", but diagnostics is implemented as "direct reference". What this means is that accessing a compiler generated member through its token will still produce all warnings (RUC or DAM) as for non-compiler-generated member. This is important for things like creation of Refactorings:
Test changes:
|
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/Dataflow/ReflectionMarker.cs
Outdated
Show resolved
Hide resolved
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/Dataflow/ReflectionMarker.cs
Outdated
Show resolved
Hide resolved
… annotations (not on type).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This modifies the behavior of both the illink and ilc to match and to implement some changes we've discussed recently - #86008.
The semantic changes (mostly as compared to previous illink behavior):
IL2118
,IL2119
andIL2120
). The plan is to eventually remove these from illink as well.Note that there are exceptions to the above rules, which can be described as: Accessing a token of a member in IL is considered a reflection access (because the token can be turned into a reflection object), but it is also considered a direct reference. So in that case marking is implemented as "reflection access", but diagnostics is implemented as "direct reference". What this means is that accessing a compiler generated member through its token will still produce all warnings (RUC or DAM) as for non-compiler-generated member. This is important for things like creation of
Action
from a lambda, where the lambda is a compiler generated method, but we need to produce warnings if it uses annotations for example.Refactorings:
ReportWarningsForReflectionAccess
- this is to mirror the design in ilc and also to make it more in sync with the already existingReportWarningsForTypeHierarchyReflectionAccess
.Test changes:
CompilerGeneratedCodeAccessedViaReflection
for ilc