Skip to content

Conversation

@jkoritzinsky
Copy link
Member

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.

…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 jkoritzinsky added area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature labels Apr 13, 2022
@jkoritzinsky jkoritzinsky added this to the 7.0.0 milestone Apr 13, 2022
@ghost ghost assigned jkoritzinsky Apr 13, 2022
@ghost
Copy link

ghost commented Apr 13, 2022

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

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.

Author: jkoritzinsky
Assignees: -
Labels:

area-System.Runtime.InteropServices, source-generator

Milestone: 7.0.0

@jkoritzinsky
Copy link
Member Author

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.
Copy link
Member

@elinor-fung elinor-fung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@jkoritzinsky
Copy link
Member Author

Yeah all of the code here was just moved around. No big logic changes in particular anywhere.

@jkoritzinsky jkoritzinsky merged commit e278502 into dotnet:main May 12, 2022
@jkoritzinsky jkoritzinsky deleted the share-more-code branch May 12, 2022 17:04
@ghost ghost locked as resolved and limited conversation to collaborators Jun 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants