Basic structure for composing stub code

[elinor-fung]

• Switch to using Roslyn APIs for syntax generation
• Add basic structure for stub code generation
  • IMarshallingGenerator - called for each stage of generation
  • StubCodeContext - context for what marshalling code should be generated
  • TypePositionInfo - type to be marshalled
• GenerateSyntax calls into the marshalling generators and uses the returned statements to create the stub code
• Basic marshallers and forwarder to run through the structure
• Test cases (just validates they compile)

[AaronRobinsonMSFT]

@elinor-fung Can we also get a Pipeline.md with a description in the designs/?

[elinor-fung]

Added a Pipeline.md with the basic structure. We can fill in more as we go.

[AaronRobinsonMSFT]

The stages look good. One question is regarding positional and implicit arguments. For example LCID creates an argument to pass and PreserveSig adds an out param to the method signature. Is this scheme able to handle that efficiently? Do we have an example/pattern for how handle those cases?

[elinor-fung]

I was thinking most of the handling would be on creating all the TypePositionInfos during processing of symbols/metadata - setting Managed/UnmanagedIndex properties accordingly and creating ones to represent an LCID argument / out param / HResult if needed. We could have specific marshalling generators for the LCID argument and HResult checking.

Then, going through the stages should not be affected other than a bit of extra cruft around declaring variables for the return value of the stub and the invoke (if needed) and determining identifier names.

I didn't want to deal with actually handling those cases yet. I can add some placeholder TODOs to indicate what I had in mind.

[jkotas]

LCID argument

FWIW, LCID arguments is an obscure legacy feature. I would be perfectly happy to not support it for the source generators if it were to add even a bit of extra complexity anywhere.

[jkoritzinsky]

One thing I've noticed with this design is the marshaler selector will need to know about the particular target scenario (P/Invoke, Reverse P/Invoke, Struct) to correctly support marshalers that either pin or allocate depending on the scenario. I'm ok with that, but I just wanted to make sure that we expected that.

[elinor-fung]

I thought that would be something that could go on the context that gets passed to the IMarshallingGenerator instances? Or am I missing something?

[jkoritzinsky]

You are correct. I misread how the context was created/passed in. This should work for those cases then.

[jkoritzinsky]

Just a few comments around places we'll have to change in the future as we add features. We can fix these now or modify them in the future when we'll need the changes.

Other than that, this looks great!

[jkoritzinsky]

Just one comment. Other than that, LGTM!