Skeleton for C#

[stephenatwork]

Not for merging! This is a placeholder PR for discussion only.

If there is interest, we have some code which handles the very basics - enums, structs, interfaces+methods. It's based on master of ~6 months ago so would need some modernizing, which we can do.

Would an incomplete implementation be accepted?
Is the layout/naming in the form you want?
Which branch should we use as a base?
Is there anything else we should be aware of?

Thanks.

[devhawk]

You're timing is pretty spot on. I pushed up an afternoon's worth of work on a C# language projection last Friday: https://github.com/microsoft/xlang/tree/devhawk/cool1. (Note "COOL" was the original code name for C# - I'm using it as a place holder name for this branch until we figure out what to name it)

So far, all I have is the publicly projected types - i.e. exactly zero implementation code, just the structure. I have some other things to work on today (May 13th) but I will definitely check this branch out!

After we get a chance to review each other's code, we should definitely chat about how to combine effort here.

To answer your other questions:

• Yes, merges into master of in-progress tools is OK - certainly that's how I did the Python/WinRT tool. We could also use a shared topic branch. My teammates working on a metadata generation tool are using this approach (example PR: Metadata for Structs #401)
• layout looks fine. Naming as per my comment above is not settled yet. In particular, we want to be able to distinguish this new tool from the existing C# language projection support in windows. I'm going to let @BrentRe figure out what to name this.
• After we review each others code, we can make a decision about what branch to use as a base. But we should be building off a more recent branch of master than 6 months old I think.
• The first goal for my effort is to enable C# developers on Mono (in particular, Unity developers) to access WinRT APIs. Mono doesn't have COM or WinRT interop support that .NET Framework and .NET Core (Windows) has. So similar to the Python projection, I'm targeting WinRT first with xplat coming later as the xplat tooling (cppxlang + xmeta) comes online.

[stephenatwork]

Thanks @devhawk - to save you time, I don't think there's much content in this PR, it's more about getting the skeleton in place. We had some projection tech with the basics, based on a custom tool with libclang. I had started to port to xlang (very smooth process btw!), but can't recall exactly how far it got. I have some additional changes which aren't in this PR.

[devhawk]

I see you made some progress on generating implementation. So far, all of my projected methods simply throw not impl!

If you've got some thoughts on interop, I'd love to hear them. We were hoping to build on C#'s proposed compiler instrinsics support but it doesn't look like that's going to make the next release. Can you share your custom tool - or at least how the custom tool does interop?

[stephenatwork]

We are using a similar technique to CppSharp. It might look something like this:
I can share the full code for our tool within MS, but not externally :(

        get {
            ushort value;
            var vslot = ((void***)instance)[0][7];
#if HAVE_INTRINSICS
            int hr = intrinsic_for_this_method(instance, &value, vslot);
#else
            var func = Marshal.GetDelegateForFunctionPointer<Delegates.Method__p_ushort>((IntPtr)vslot);
            int hr = func(instance, &value);
#endif
            if (hr < 0)
                throw new Exception(…);
            return value;
        }

[jkoritzinsky]

You might want to take a look at the SharpGenTools project as inspiration for a way to do the reverse-callback direction (passing C# implementations to other xlang languages).

[stephenatwork]

Closing this PR. The https://github.com/microsoft/xlang/tree/devhawk/cool1 branch obsoletes it.