-
Notifications
You must be signed in to change notification settings - Fork 509
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
Collect incremental state without passing compilation to output stage #3452
Conversation
@@ -30,22 +30,70 @@ private enum NodeKind | |||
|
|||
public void Initialize(IncrementalGeneratorInitializationContext context) | |||
{ | |||
var compilation = context.CompilationProvider; | |||
var referencedAssemblies = context.CompilationProvider.SelectMany( |
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.
@chsienki this is IncrementalValuesProvider<IAssemblySymbol>
, which should be efficient provided the IAssemblySymbol
for a metadata reference is carried forward from one compilation to the next. Do you know if this is true for the IDE and/or command line?
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, they should be carried forward. There is also context.MetadataReferences
which provides the same thing. You don't get the IAssemblySymbol
directly, but if you new up a compilation with the reference you can retrieve it, and the input will then never change unless the user adjusts references.
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.
I'll switch over to context.MetadataReferences
after 4.2.0 is released (this is the version that corrects the signature for this property).
{ | ||
} | ||
|
||
private record ExistingTypeData(string TypeName, ImmutableArray<string> MemberNames) |
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.
@chsienki is there a straightforward way to have a properly equatable list of strings in a record, without having to implement custom equality?
@@ -1393,5 +1441,20 @@ public string GetAccessorResultType(SyntaxData syntaxData) | |||
return null; | |||
} | |||
} | |||
|
|||
private record CompilationData(ImmutableDictionary<string, ExistingTypeData> ExistingTypes) |
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.
@chsienki is there a straightforward way to have a properly equatable dictionary in a record, without having to implement custom equality?
Codecov Report
@@ Coverage Diff @@
## master #3452 +/- ##
==========================================
- Coverage 93.23% 92.95% -0.28%
==========================================
Files 1063 1063
Lines 113033 136647 +23614
Branches 3980 7071 +3091
==========================================
+ Hits 105383 127020 +21637
- Misses 6630 8421 +1791
- Partials 1020 1206 +186 |
#nullable enable | ||
|
||
// NOTE: This code is derived from an implementation originally in dotnet/runtime: | ||
// https://github.com/dotnet/runtime/blob/v5.0.3/src/libraries/System.Private.CoreLib/src/System/HashCode.cs |
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.
Could you reference Microsoft.Bcl.HashCode instead?
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.
I prefer to avoid dependencies in the source generator, since it makes build integration much more complex.
No description provided.