Skip to content

Conversation

@avrabe
Copy link
Contributor

@avrabe avrabe commented Jan 27, 2026

Summary

  • Register MoonBit hermetic toolchain in MODULE.bazel (was declared but never registered)
  • Set MOON_HOME in moonbit_wasm_component build script for core library access
  • Include moonbit_all_files in sandbox inputs for hermetic builds
  • Add --encoding utf16 to wasm-tools component embed (MoonBit string encoding)
  • Update rules_moonbit to commit with chmod + core bundle fixes

Test Plan

  • bazel build //examples/moonbit_component:calculator succeeds
  • wasm-tools component wit shows correct exports (add, subtract, multiply, divide)
  • wasm-tools validate passes
  • bazel build //examples/moonbit_component:hello_wasi still works

Closes #304

🤖 Generated with Claude Code

Three issues prevented moonbit_wasm_component from building:

1. MoonBit toolchain was never registered - MODULE.bazel declared
   bazel_dep(name = "rules_moonbit") but never called use_extension
   or register_toolchains, causing Bazel to use the stub toolchain

2. MOON_HOME not set - moon build couldn't find moonbitlang/core
   standard library inside the Bazel sandbox

3. Missing sandbox inputs - moonbit_all_files wasn't included in
   action inputs, so the toolchain binaries (moonc, etc.) weren't
   available in the sandbox

Also adds --encoding utf16 to wasm-tools component embed (required
for MoonBit string encoding) and updates rules_moonbit to the commit
with chmod + core bundle fixes.

Verified: calculator component builds and exports correct WIT:
  export add: func(a: s32, b: s32) -> s32
  export subtract: func(a: s32, b: s32) -> s32
  export multiply: func(a: s32, b: s32) -> s32
  export divide: func(a: s32, b: s32) -> s32

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@avrabe avrabe force-pushed the fix/moonbit-component-toolchain branch from ef147ad to 220c8f5 Compare January 27, 2026 05:47
avrabe and others added 3 commits January 28, 2026 06:05
Add explicit import of CcToolchainConfigInfo from @rules_cc in both
wasi_sdk_toolchain.bzl (generated template) and wasm_cc_toolchain.bzl.

Bazel 9 removed CcToolchainConfigInfo as a global built-in, so
`provides = [CcToolchainConfigInfo]` evaluates to `provides = [None]`
without the import, causing rule definition failures.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
In Bazel 9, cc_common is no longer a global built-in - it must be
explicitly imported from @rules_cc//cc/common:cc_common.bzl. Also
switch cc_toolchain_config_lib imports from @bazel_tools to @rules_cc
to match the canonical pattern from rules_cc examples.

This fixes the "struct has no field create_cc_toolchain_config_info"
error when building with Bazel 9.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Bazel 9 removed CcInfo and cc_common from the built-in globals.
Add explicit imports from @rules_cc for all files that use them:

- cpp/defs.bzl: CcInfo + cc_common
- cpp/private/cpp_wasm_binary.bzl: CcInfo
- rust/private/rust_wasm_component_bindgen.bzl: CcInfo
- test/cpp/cpp_component_tests.bzl: CcInfo

These imports are backward-compatible with Bazel 8.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WebAssembly Component Model Support for MoonBit Integration

2 participants