-
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
Implement type name resolution for ILLink analyzer #106209
Conversation
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.
A couple style/organization nits, but LGTM otherwise, thank you!
src/tools/illink/src/ILLink.Shared/TrimAnalysis/RequireDynamicallyAccessedMembersAction.cs
Outdated
Show resolved
Hide resolved
readonly Location _location; | ||
readonly Action<Diagnostic>? _reportDiagnostic; |
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.
Do we need these in addition to the _diagnosticContext
? I don't see anywhere where they would have different values
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.
Yes, _location
needs to be separate so that we can pass it through to ReflectionAccessAnalyzer
, see #105956 for more context.
src/tools/illink/src/ILLink.RoslynAnalyzer/TrimAnalysis/TypeNameResolver.cs
Outdated
Show resolved
Hide resolved
|
||
namespace ILLink.Shared.TrimAnalysis | ||
{ | ||
internal partial struct RequireDynamicallyAccessedMembersAction | ||
{ | ||
readonly Compilation _compilation; |
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.
nit: It looks like this Compilation
is only ever passed down to ReflectionAccessAnalyzer.TryResolveTypeNameAndMark()
to create the same TypeNameResolver
. Maybe we could just have a TypeNameResolver
field instead? And we could then call TryResolveTypeNameAndMark
directly on that field and remove ReflectionAccessAnalyzer.TryResolveTypeNameAndMark()
.
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.
Changed this to pass around TypeNameResolver instead of Compilation, and made it a field of ReflectionAccessAnalyzer. I didn't get rid of TryResolveTypeNameAndMark
from ReflectionAccessAnalyzer, to keep the code structure similar to ReflectionMarker.
src/tools/illink/test/Mono.Linker.Tests.Cases/DataFlow/AssemblyQualifiedNameDataflow.cs
Outdated
Show resolved
Hide resolved
- Remove unused using - Simplify string concatenation - Remove unnecessary partial - Pass around TypeNameResolver instead of Compilation
The repo no longer builds locally for me after this PR. I get
Any idea why? |
@@ -28,6 +31,7 @@ | |||
<PrivateAssets>all</PrivateAssets> | |||
<ExcludeAssets>contentfiles</ExcludeAssets> <!-- We include our own copy of the ClosedAttribute to work in source build --> | |||
</PackageReference> | |||
<PackageReference Include="System.Reflection.Metadata" Version="$(SystemReflectionMetadataVersion)" /> |
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.
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.
Yeah, an analyzer should only be using the version of SRM that roslyn provides for it.
It could be possible for an analyzer to carry a newer version of SRM, but it would need to be copied/deployed with the analyzer (and have a different version than the one in roslyn) - and we'd need to make sure to never try to exchange SRM types with the compiler (I don't think any SRM types are part of roslyn's public API but I can't be certain).
It might be possible to have this work once we upgrade to preview7 SDK, but I think it might still be broken in the editor/design-time build if VS itself doesn't have the new SRM.
Fixes #95118