Various refactorings to share more code with future generators #67997
Conversation
…xContext. Move IMarshallingGeneratorFactory creation into LibraryImportGenerator. Create InteropAttributeData base type for attribute info. Better represent how to ensure incrementality with IMarshallingGeneratorFactory instances without making them IEquatable themselves.
…pper around DllImport. Create extension methods to use in IIncrementalGenerator implementations
Use an extension method to report diagnostics easily.
…ators that have specific requirements require less copy-paste.
jkoritzinsky
added
area-System.Runtime.InteropServices
source-generator
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsRefactor a lot of code out of LibraryImportGenerator.csproj and into Microsoft.Interop.SourceGeneration.csproj so we can reuse more of it with the upcoming COM source generator. This PR moves many of the building blocks for the way the interop team has designed our source generators into a more shareable design and makes most of LibraryImportGenerator into glue between the building blocks and special LibraryImportGenerator-only features.
|
|
This PR also removes an old warning that only fires in "unsupported" scenarios that will never come up for consumers (custom CoreLib assembly) that caused additional complexity. |
…incremental tests changed as the tree traversal that records all of the steps was recording the cases that reported diagnostics first. Update the incremental tests to not report diagnostics to ensure that step order matches SyntaxTree order.
…l it into the context type we pass)
There was a problem hiding this comment.
I really just looked at how PInvokeStubCodeGenerator now composes the generated code - which seems reasonable to me. I'm assuming all most of the added code is just copied/moved with slight tweaks to fit nicely in their new place - is there a specific part we should look at closely?
...ibraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.cs
Outdated
Show resolved
Hide resolved
...es/System.Runtime.InteropServices/gen/Microsoft.Interop.SourceGeneration/SyntaxExtensions.cs
Show resolved
Hide resolved
...en/Microsoft.Interop.SourceGeneration/IncrementalGeneratorInitializationContextExtensions.cs
Outdated
Show resolved
Hide resolved
...es/System.Runtime.InteropServices/gen/Microsoft.Interop.SourceGeneration/SignatureContext.cs
Outdated
Show resolved
Hide resolved
...em.Runtime.InteropServices/gen/Microsoft.Interop.SourceGeneration/ContainingSyntaxContext.cs
Outdated
Show resolved
Hide resolved
...es/System.Runtime.InteropServices/gen/Microsoft.Interop.SourceGeneration/SignatureContext.cs
Outdated
Show resolved
Hide resolved
...es/System.Runtime.InteropServices/gen/Microsoft.Interop.SourceGeneration/SignatureContext.cs
Outdated
Show resolved
Hide resolved
...System.Runtime.InteropServices/gen/Microsoft.Interop.SourceGeneration/GeneratedStatements.cs
Outdated
Show resolved
Hide resolved
...es/System.Runtime.InteropServices/gen/Microsoft.Interop.SourceGeneration/SignatureContext.cs
Outdated
Show resolved
Hide resolved
|
Yeah all of the code here was just moved around. No big logic changes in particular anywhere. |
Refactor a lot of code out of LibraryImportGenerator.csproj and into Microsoft.Interop.SourceGeneration.csproj so we can reuse more of it with the upcoming COM source generator.
This PR moves many of the building blocks for the way the interop team has designed our source generators into a more shareable design and makes most of LibraryImportGenerator into glue between the building blocks and special LibraryImportGenerator-only features.