Wasm marshaler registration source generator

[maraf]

• We are no generating MarshalerAttribute, Interop.Runtime.InvokeJS and MarshalerInitializer.
• Custom attribute with [Marshaler(typeof(...))] syntax.
• The attribute can be used multiple times on a marshaler class.

MarshalerAttribute.g.cs

namespace System.Runtime.InteropServices.JavaScript
{
    [AttributeUsageAttribute(AttributeTargets.Class, AllowMultiple = true)]
    internal sealed class MarshalerAttribute : Attribute
    {
        public MarshalerAttribute(Type marshaledType)
        {
        }
    }
}

Interop.Runtime.g.cs

using System.Runtime.CompilerServices;

internal static class Interop
{
  internal static class Runtime
  {
    [MethodImpl(MethodImplOptions.InternalCall)]
    internal static extern string InvokeJS(string str, out int exceptionalResult);
  }
}

MarshalerInitializer.g.cs sample

class MarshalerInitializer
{
    [System.Runtime.CompilerServices.ModuleInitializer]
    internal static void Initialize()
    {
        int temp;
        Interop.Runtime.InvokeJS($"MONO.mono_wasm_register_custom_marshaler('{typeof(System.DateTime).AssemblyQualifiedName}', '{typeof(System.Runtime.InteropServices.JavaScript.DateTimeMarshaler).AssemblyQualifiedName}');", out temp);
        Interop.Runtime.InvokeJS($"MONO.mono_wasm_register_custom_marshaler('{typeof(System.DateTimeOffset).AssemblyQualifiedName}', '{typeof(System.Runtime.InteropServices.JavaScript.DateTimeOffsetMarshaler).AssemblyQualifiedName}');", out temp);
        Interop.Runtime.InvokeJS($"MONO.mono_wasm_register_custom_marshaler('{typeof(System.Uri).AssemblyQualifiedName}', '{typeof(System.Runtime.InteropServices.JavaScript.UriMarshaler).AssemblyQualifiedName}');", out temp);
    }
}

I'm not sure about project name and location, please suggest better for both.

[pavelsavara]

Maybe in generated code you should do typeof(System.Runtime.InteropServices.JavaScript.DateTimeMarshaler) instead of just string literal, so that AOT linker knows that you are using it.

[maraf]

@kg The Interop.Runtime.InvokeJS is internal and I can't use it in the tests assembly.
Should I add InternalsVisibleToAttribute to the tests project for now?

Or @pavelsavara has the idea that I could generate a header for mono_wasm_register_custom_marshaler in the MarshalerInitializer.

[maraf]

Or @pavelsavara has the idea that I could generate a header for mono_wasm_register_custom_marshaler in the MarshalerInitializer.

Ok, that doesn't work with

  fail: [FAIL] System.Runtime.InteropServices.JavaScript.Tests.DelegateTests.RejectPromiseError
  info: System.TypeInitializationException : The type initializer for '<Module>' threw an exception.
  info: ---- System.MissingMethodException :  assembly:<unknown assembly> type:<unknown type> member:(null)
  info:    at System.Reflection.RuntimeMethodInfo.InvokeWorker(Object obj, BindingFlags invokeAttr, Span`1& parameters) in C:\Development\dotnet\runtime\src\mono\System.Private.CoreLib\src\System\Reflection\RuntimeMethodInfo.Mono.cs:line 386
  info: ----- Inner Stack Trace -----
  info:    at MarshalerInitializer.Initialize() in C:\Development\dotnet\runtime\src\libraries\System.Private.Runtime.InteropServices.JavaScript\tests\System.Private.Runtime.InteropServices.JavaScript.MarshalerGenerator\System.Runtime.InteropServices.JavaScript.MarshalerGenerator.MarshalerRegistrationGenerator\MarshalerInitializer.g.cs:line 7
  info:    at <Module>..cctor()
  info: Finished:    System.Private.Runtime.InteropServices.JavaScript.Tests.dll

[maraf]

I will start a new "public" JavaScript library here, so the attribute and generator can be consumed in other projects.

[kg]

My understanding is we already have a tasks assembly that contains source generators for other wasm-related things, maybe we can put this there?

[maraf]

The problem here is that
a) we need to put the MarshalerAttribute somewhere that user code has a reference to,
b) we need a publicly visible JavaScript interop API, because the generated MarshalerInitializer needs access to it.

The generator itself can be anywere.

[pavelsavara]

That is good opportunity to draft public API assembly here. And learn how to make it public and included with runtime.
We could later move things from private interop namespace, which we agree that have nice enough API.

[kg]

Adding a public API will require review, which I think we want to avoid at this point. I think we can do like other new features do and match the attribute by name so that an assembly can provide the attribute itself until we make it public (if ever). For the registration function, we can do a similar trick since icalls are matched by name - we can just put the icall in the assembly next to the generated module initializer.

On November 23, 2021 12:39:41 PM PST, Pavel Savara ***@***.***> wrote: That is good opportunity to draft public API assembly here. And learn how to make it public and included with runtime. We could later move things from private interop namespace, which we agree that have nice enough API. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2 (comment)

- kg (mobile)

[maraf]

I think we can do like other new features do and match the attribute by name so that an assembly can provide the attribute itself until we make it public (if ever).

Yes, this is doable.

For the registration function, we can do a similar trick since icalls are matched by name - we can just put the icall in the assembly next to the generated module initializer.

I tried it, but it did not work. I'll ping you tomorrow with the code I had.

[maraf]

I can even generate the attribute itself...

[pavelsavara]

Thinking aloud. Maybe we could have multiple ways.

1. attribute which is linker friendly, on the marshalled type.
2. attribute which is doesn't reference the target type (like Uri) by type ref, but only by type full name string. Then we would try to find the type via reflection on runtime. If we found it we would register the marshaller.

The problem with 2) is that code of marshaller itself is using the marshalled type. Could we somehow tell the linker to ignore it ? Or tell the runtime to late-bind it ?

dynamic keyword or reflection comes to mind. But they are vastly inefficient.
Could we load marshaller from separate DLL on demand ?

Separate the registration from the implementation ?

[pavelsavara]

https://www.codeguru.com/cplusplus/arranging-custom-marshaling-with-p-invoke/

We could also have the attribute at the method which wants to use custom marshaller. In the same way as PInvoke.

Being able to customize marshaller locally, not globally is probably right approach anyway.

[maraf]

Event if we annotate the type with the attribute and marshaler in it, the linker won't be able to trim it when the type is used somewhere in the app, although it's not used in the interop.

From the linker perspective it's the solution to apply the attribute on the interop method itself. Because if the method is not used, it will be trimmed and so the marshaler type. But it is kind a annoying from user perspective.

Is there a way to determine which method is used "in the interop"?

[kg]

https://www.codeguru.com/cplusplus/arranging-custom-marshaling-with-p-invoke/

We could also have the attribute at the method which wants to use custom marshaller. In the same way as PInvoke.

Being able to customize marshaller locally, not globally is probably right approach anyway.

FYI, this old API explicitly was called out as a bad design when we previously did API review for JS custom marshalers. So we shouldn't be using it as an example.

[kg]

I squashed+rebased this and shoved it at https://github.com/kg/runtime/tree/maraf-sourcegen, will be forking off that to mess with integrating a source generator into my PR since it has a C#-based code generator now.

[kg]

From testing this, the removal of the .xml files breaks it because the linker is now stripping all of the statics out of the marshalers.