Skip to content

Conversation

pavelsavara
Copy link
Member

@pavelsavara pavelsavara commented Sep 13, 2025

There are C symbols that are used by PAL or ICall and are implemented in browser specific C or JavaScript.
Many of them would be re-used by coreCLR and are also already used by NAOT_LLVM.

Here I suggest that instead of mono_wasm prefix we adopt dotnet_browser prefix.
All of them are snake_case at the moment like dotnet_browser_random_bytes

But they could also adopt native libraries style BrowserNative_RandomBytes we use by DllImportEntry().
Perhaps that would be good when we start standing up the TypeScript and C code for browser/CLR in src\native\libs\Browser.Native and keep consistent style.

@pavelsavara pavelsavara added this to the 11.0.0 milestone Sep 13, 2025
@pavelsavara pavelsavara self-assigned this Sep 13, 2025
@pavelsavara pavelsavara added arch-wasm WebAssembly architecture area-Build-mono os-browser Browser variant of arch-wasm labels Sep 13, 2025
@pavelsavara pavelsavara marked this pull request as ready for review September 13, 2025 08:24
@Copilot Copilot AI review requested due to automatic review settings September 13, 2025 08:24
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR renames C symbols used by browser-specific JavaScript and C code from the mono_wasm prefix to the dotnet_browser prefix. The purpose is to prepare these symbols for potential reuse by CoreCLR and align with existing NAOT_LLVM usage.

Key Changes

  • Renamed functions from mono_wasm_* to dotnet_browser_* prefix across all browser runtime files
  • Updated function calls and exports to use the new naming convention
  • Modified internal calls and binding registrations to reference the renamed functions

Reviewed Changes

Copilot reviewed 32 out of 32 changed files in this pull request and generated no comments.

Show a summary per file
File Description
src/native/minipal/random.c Updated external function declaration and call to use dotnet_browser_random_bytes
src/mono/wasm/threads.md Updated documentation references to use new function names
src/mono/wasi/runtime/driver.c Updated external function declarations for GC root management
src/mono/mono/utils/mono-threads.h Updated function declarations for background job scheduling
src/mono/mono/utils/mono-threads-wasm.c Renamed background job scheduling functions and debug messages
src/mono/mono/mini/mini-wasm.h Updated timer scheduling function declaration
src/mono/mono/mini/mini-wasm.c Renamed timer and synchronization functions, updated internal call registrations
src/mono/mono/metadata/sgen-mono.c Updated background job scheduling call
src/mono/mono/metadata/gc.c Updated background job scheduling call
src/mono/browser/runtime/web-socket.ts Updated comment reference to new function name
src/mono/browser/runtime/roots.ts Updated GC root registration/deregistration function calls
src/mono/browser/runtime/pthreads/worker-interop.ts Renamed worker interop uninstall function
src/mono/browser/runtime/pthreads/index.ts Updated exports and renamed warning function
src/mono/browser/runtime/marshal-to-js.ts Renamed promise resolution functions and updated GC root calls
src/mono/browser/runtime/marshal-to-cs.ts Updated GC root registration calls
src/mono/browser/runtime/logging.ts Renamed console clear function
src/mono/browser/runtime/invoke-js.ts Renamed JS import binding and invocation functions
src/mono/browser/runtime/invoke-cs.ts Renamed assembly exports function
src/mono/browser/runtime/globalization-locale.ts Renamed locale info function
src/mono/browser/runtime/gc-handles.ts Renamed CS owned object release function
src/mono/browser/runtime/gc-common.h Updated GC root function declarations
src/mono/browser/runtime/exports-binding.ts Updated all import statements and exports array
src/mono/browser/runtime/export-api.ts Updated assembly exports import
src/mono/browser/runtime/driver.c Renamed GC root registration functions
src/mono/browser/runtime/cwraps.ts Updated function signatures and interface
src/mono/browser/runtime/crypto.ts Renamed random bytes function
src/mono/browser/runtime/corebindings.c Extensive renaming of extern declarations, function definitions, and internal call registrations
src/mono/browser/runtime/cancelable-promise.ts Renamed promise cancellation functions
src/libraries/System.Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/Marshaling/JSMarshalerArgument.Task.cs Updated comment reference
src/libraries/System.Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/JSFunctionBinding.cs Updated comment reference
src/libraries/System.Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/Interop/JavaScriptExports.cs Updated comment reference
src/coreclr/vm/wasm/helpers.cpp Renamed function and updated error message

@maraf
Copy link
Member

maraf commented Sep 13, 2025

I don't see much value in dotnet_ prefix, as all of it is internal (IIUC)

@pavelsavara
Copy link
Member Author

I don't see much value in dotnet_ prefix, as all of it is internal (IIUC)

In case there are 3rd party libraries linked into the same .wasm file, we don't want to clash.

As I'm working on the host, the idea of BrowserNative_RandomBytes and src\native\libs\Browser.Native makes more and more sense.

@SingleAccretion
Copy link
Contributor

I think functions like mono_wasm_browser_entropy should be prefixed by the name of their respective native shim (like SystemNative_GetBrowserEntropy, there are also some globalization-related ones). Actually, I would like to see these small helpers implemented as Emscripten JS libraries / EM_JS for linking and layering reasons, but that's a separate conversation.

For the JS interop ones, I don't have a strong opinion (they could be prefixed with SystemJSInterop I guess...).

@pavelsavara
Copy link
Member Author

Actually, I would like to see these small helpers implemented as Emscripten JS libraries / EM_JS for linking and layering reasons

I hear you @SingleAccretion, let's have separate conversation in #119685

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-wasm WebAssembly architecture area-Build-mono os-browser Browser variant of arch-wasm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants