Export a working synth_compile rule and bundle meld/synth as hermetic toolchains

[avrabe]

Thanks for rules_wasm_component — the hermetic wasm toolchain bundles are great to build on. While wiring jess (a hardware-integration project that builds falcon firmware: wasm component → meld fuse → synth → Cortex-M ELF → Renode), I hit two gaps that block expressing the firmware build hermetically. Filing together since they're the same "downstream firmware build" story.

1. synth_compile isn't usable

relay/BUILD.bazel loads synth_compile from @rules_wasm_component//wasm:defs.bzl but the call is disabled with:

"Temporarily disabled: synth_compile rule now requires a synth attribute that this file doesn't provide."

So there's no working path to compile a fused core module to a Cortex-M ELF via the rules.

2. meld/synth aren't bundled as hermetic toolchains

meld_fuse lives in @meld//rules:meld.bzl, and synth is @synth//crates:synth. To use them a consumer must bazel_dep on meld and synth — which drags their rules_verus / rules_rocq_rust / rules_lean (Nix) proof toolchains into a firmware-only build. A firmware consumer shouldn't need the proof toolchains.

Impact

jess can hermetically wasm_validate + wasm_optimize the falcon component today, but cannot express meld_fuse → synth_compile → renode_test without either (a) an unimplemented rule or (b) pulling in the full verification stack. For now we fall back to the prebuilt CLIs in a shell script.

Suggested direction

• Finish/export synth_compile with a synth toolchain attribute (analogous to how the wasm bundle registers wasm-tools), so synth_compile(wasm_module=…, target="cortex-m4f") works standalone.
• Provide meld/synth as hermetic toolchains from rules_wasm_component (or thin rules_meld/rules_synth) that fetch prebuilt binaries, so a firmware build doesn't depend on the proof toolchains.

Happy to test against the falcon component (relay falcon-flight-v1.27.wasm) once there's something to try. Thanks!

[avrabe]

Small follow-up while integrating from jess: to consume a prebuilt/released component (relay's falcon-flight.wasm) I needed a WasmComponentInfo, and there's no adopt/import rule, so I wrote a tiny local shim that works for wasm_validate:

load("@rules_wasm_component//providers:providers.bzl", "WasmComponentInfo")
def _impl(ctx):
    f = ctx.file.wasm
    return [DefaultInfo(files = depset([f])),
            WasmComponentInfo(wasm_file = f, wit_info = None, component_type = "component",
                              imports = [], exports = [], metadata = {}, profile = "release",
                              profile_variants = {})]
adopt_wasm_component = rule(implementation = _impl,
    attrs = {"wasm": attr.label(allow_single_file = [".wasm"], mandatory = True)})

Would a first-class wasm_component_import / adopt rule (deriving wit_info/imports/exports from the component where possible) be welcome upstream? Happy to contribute it. (wasm_optimize on such an adopted component hits a separate input-staging bug — filed as #490.) Thanks!

[avrabe]

Gentle nudge from the jess loop — still relevant, and the offer stands. The concrete need is unchanged: consuming a prebuilt/released component (relay's falcon-flight.wasm) currently requires the local adopt_wasm_component shim above just to get a WasmComponentInfo, and the firmware chain (synth_compile toolchains) still can't be expressed without dragging meld/synth's proof toolchains in.

Happy to send a PR for a first-class wasm_component_import / adopt rule (deriving wit_info/imports/exports where possible) if that direction is welcome — just confirm you'd take it and I'll open it. No rush; flagging so it doesn't go stale.

[avrabe]

Re-ping with fresh context, not just a bump: now that #490 is merged and jess's hermetic fetch → validate → optimize chain runs on rwc main (//:falcon-optimized green, SIL-gated), the two items in this issue are the next gate for the fuse → compile → emulate stage:

1. a first-class prebuilt-component adopt rule (jess still carries the local adopt_wasm_component shim to get a WasmComponentInfo from relay's released falcon-flight.wasm), and
2. a working synth_compile rule + meld/synth toolchains.

The offer stands and is shovel-ready: happy to open a PR for wasm_component_import (deriving WasmComponentInfo, with imports/exports where resolvable) against main — just greenlight the direction and I'll send it. No rush; flagging so it stays on the radar as the optimize chain is now unblocked.

[avrabe]

Greenlit — please send the wasm_component_import PR. 👍

Direction that'll merge smoothly:

• Return WasmComponentInfo with wasm_file set to the adopted .wasm; component_type = "component", profile = "release", empty profile_variants.
• Derive imports/exports where resolvable (e.g. wasm-tools component wit / the wasm_tools_component toolchain) and fall back to empty lists when not — don't hard-fail on a stripped component.
• wit_info = None is fine when no WIT is available (matches the shim).
• Put it under wasm/ with the other rules; wire it into wasm/defs.bzl exports + a bzl_library in wasm/private/BUILD.bazel. A small examples/ adopt-then-validate/optimize target makes a good test (the falcon component is a natural fixture).

On item 2 — synth_compile already landed on main as a hermetic toolchain (#468); it's exported from wasm/defs.bzl and no longer disabled, and meld_fuse/synth toolchains are in too. Could you confirm your fuse → compile → emulate stage builds against main's synth_compile? If it does, this issue narrows to just the adopt rule (item 1) and we can check item 2 off.

[avrabe]

Item 2 confirmed — fuse → compile builds against v1.1.0's synth_compile. jess bumped its pin to the v1.1.0 tag and wired:

adopt_wasm_component(:falcon-flight)         # the shim this issue's item 1 replaces
  → meld_fuse(:falcon-fused, validate=True)
  → synth_compile(:falcon-firmware, target="cortex-m4f", all_exports=True)

bazel build //:falcon-fused //:falcon-firmware → green, fully hermetic (no verus/rocq/lean toolchains pulled):

• //:falcon-fused — wasm-tools validate VALID
• //:falcon-firmware — 32-bit ARM EABI5 ELF, 24 funcs, .linear_memory + vector table, link-survivable relocs (synth#345). (Exports-only until synth#275 dispatch lands — a synth codegen item, not a rules issue.)

So item 2 is done — this issue narrows to just item 1 (the adopt rule). PR for wasm_component_import incoming per your greenlight + direction. Thanks!