LibraryImport with custom StringMarshalling type causes the source generator to keep the Compilation object alive #78242
Comments
jkoritzinsky
added
area-System.Runtime.InteropServices
source-generator
|
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsDescriptionWhen using the Reproduction StepsI've included a test case (commented out) in this commit Expected behaviorThe test should pass. Actual behaviorThe test fails. Regression?No response Known WorkaroundsNo response ConfigurationNo response Other informationThe problem is that the We need to change how we pass the attribute data between the "compute the model" stage and the "generate code" stage such that the information we need is available, but the symbols are not passed while still having a decently understandable API.
|
AaronRobinsonMSFT
removed
the
untriaged
jkoritzinsky
changed the title
ghost
added
the
in-pr
…#79051) Fixes #78242 Creates separate types for InteropAttributeData: one that holds compilation data (InteropAttributeCompilationData), and one that holds only the data necessary for the model to create the generated code (InteropAttributeModelData). This uncovered some issues with record equality in records that use SyntaxNode. For those, we need to override Equals or wrap the SyntaxNode in a type that overrides Equals to use IsEquivalentTo on the SyntaxNode. There are probably more places where we use SyntaxNode that aren't caught in the current tests. To make sure every record has the right equality, I wasn't sure if it would be better to override Equals for each of the records, or create a wrapper record struct for each SyntaxNode that implements the equality we want (and implicit casts to and from the SyntaxNode). Then we wouldn't have to explicitly override the equality in each record that has a SyntaxNode. I also overrode both Equals and GetHashCode, but I'm not confident in my GetHashCode implementation. It could also be done with IEquatable.Equals without needing GetHashCode, but that would require implementing the TypeSyntax equality for every type that inherits from ManagedTypeInfo.
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Description
When using the
StringMarshallingCustomTypeproperty on aLibraryImportattribute, the generator caches a symbol object, causing the compilation to be kept alive across runs of the generator.Reproduction Steps
I've included a test case (commented out) in this commit
32f856c(#77130)Expected behavior
The test should pass.
Actual behavior
The test fails.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
The problem is that the
LibraryImportDatarecord type contains a property for theStringMarshallingCustomTypeproperty fromLibraryImportAttributeand we put that property into our "data model" typeIncrementalStubGenerationContext:runtime/src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.cs
Line 30 in 2b1f57e
We need to change how we pass the attribute data between the "compute the model" stage and the "generate code" stage such that the information we need is available, but the symbols are not passed while still having a decently understandable API.
The text was updated successfully, but these errors were encountered: