Function signature mismatch when calling native WASM function that takes i64/long

[r58Playz]

Description

An Uncaught RuntimeError: null function or function signature mismatch is thrown when attempting to call a [DllImport]ed function that takes an enum with ulong variant on WASM.

Reproduction Steps

Default wasmbrowser template with these changes:

Program.cs

using System;
using System.Runtime.InteropServices;
using System.Runtime.InteropServices.JavaScript;

Console.WriteLine("Hello, Browser!");

[Flags]
public enum Flags  : ulong { X = 1 }

public partial class MyClass
{
    [JSExport]
    internal static string Greeting()
    {
        i64func(Flags.X);
        var text = $"Hello, World!";
        Console.WriteLine(text);
        return text;
    }

    [DllImport("Program")]
    extern static void i64func(Flags var);
}

Program.c

#include <stdio.h>
#include <stdint.h>

void i64func(uint64_t var) {
	printf("test %lld \n", var);
}

i64-fail.csproj

<Project Sdk="Microsoft.NET.Sdk.WebAssembly">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <WasmBuildNative>true</WasmBuildNative>
  </PropertyGroup>

  <ItemGroup>
    <NativeFileReference Include="Program.c" />
  </ItemGroup>
</Project>

Expected behavior

i64func should print the number that it was passed to the console when called.

Actual behavior

i64func throws Uncaught RuntimeError: null function or function signature mismatch when called.

Regression?

No response

Known Workarounds

No response

Configuration

• OS: Arch Linux
• dotnet: 9.0.102
• Host architecture: x86_64
• Browser: Chrome, Firefox

Other information

No response

Edit: Made my repro closer to what my full code is erroring on and fixed image

[lewing]

@kg any idea what might be going wrong here?

[kg]

Does it work if you cast the enum to uint64 and make the signature of the pinvoke uint64?

[r58Playz]

Yes, it works fine if I do that.

[kg]

I think we historically have some limitations around enums and basetypes, so this is probably one of those cases. I know JS interop previously treated all enums as int32 so it doesn't surprise me that the same is true for pinvoke.

For now, please use the workaround, but we'll definitely keep this issue open and try to fix it.