Upgrade wasmtime to 41.0.1 and wasmi to 1.0.7 by lukehutch · Pull Request #72 · juancastillo0/wasm_run

lukehutch · 2026-01-30T06:52:36Z

wasmtime: 14.0.4 → 41.0.1 with full WASI Preview1 + Preview2 support, including WasmGC
wasmi: 0.31.0 → 1.0.7 with SIMD, multi-memory, memory64, tail-call support
Add component-model feature for WIT support in wasmtime
Add centralized error messages for unsupported features (errors.rs)
Add GC type wrappers (WAnyRef, WExnRef) for wasmtime GC proposal
Fix API changes: ValType, StackLimits, FuncRef/ExternRef, Memory/Table u64
All tests pass

Changes were created by Claude Code (4.5 Opus / MAX).

- wasmtime: 14.0.4 → 41.0.1 with full WASI Preview1 + Preview2 support - wasmi: 0.31.0 → 1.0.7 with SIMD, multi-memory, memory64, tail-call support - Add component-model feature for WIT support in wasmtime - Add centralized error messages for unsupported features (errors.rs) - Add GC type wrappers (WAnyRef, WExnRef) for wasmtime GC proposal - Fix API changes: ValType, StackLimits, FuncRef/ExternRef, Memory/Table u64 - Format Dart bridge code

lukehutch · 2026-01-30T06:53:05Z

Fixes #71

- Create wasm_run_native Flutter FFI plugin package - Add Cargokit for automatic Rust compilation during Flutter build - Move Rust native code to wasm_run_native/native - Update wasm_run_flutter to depend on wasm_run_native - Remove binary downloading from wasm_run_flutter platform scripts - Update Cargo workspace to use wasm_run_native as canonical location This enables building native libraries from source instead of downloading precompiled binaries, which: - Eliminates external binary dependency - Allows custom feature flags and optimization - Supports all Cargokit cross-compilation targets Supported platforms via Cargokit: - Linux: x86_64, aarch64 - macOS: x86_64, arm64 - Windows: x86_64 - iOS: arm64, arm64-sim, x86_64-sim - Android: arm64-v8a, armeabi-v7a, x86, x86_64

lukehutch · 2026-01-30T09:41:51Z

I took the liberty of splitting out the native libraries into a new wasm_run_native package, because I want to be able to depend upon that from wasm_run without having to add the wasm_run_flutter package (for serverside, non-Flutter wasm).

Rust dependencies updated: - flutter_rust_bridge: 1.82.4 → 1.82.6 - anyhow: 1.0.75 → 1.0.100 - once_cell: 1.18.0 → 1.21.3 - wat: 1.227 → 1.244.0 - rayon: 1.8.0 → 1.11.0 - cap-std: 2.0.0 → 4.0.0 - wasmi: 1.0.7 → 1.0.8 Dart dependencies updated: - SDK constraint: >=3.3.0 <4.0.0 - Flutter constraint: >=3.19.0 - meta: ^1.15.0 - ffi: ^2.1.3 - freezed_annotation: ^2.4.4 - logging: ^1.3.0 - collection: ^1.19.0 - ffigen: ^15.0.0 - test: ^1.26.0 - build_runner: ^2.4.13 - very_good_analysis: ^6.0.0 - plugin_platform_interface: ^2.1.8 - args: ^2.7.0 Note: flutter_rust_bridge v2.x requires significant code restructuring and is not included in this update. The v1.x line remains compatible with the current codebase.

- Add #[allow(dead_code)] to unused Preview2 code (WasiP2State, make_wasi_p2_ctx) - Add #[allow(dead_code)] to ModuleIOWriter in wasmtime build - Add #[allow(dead_code)] to preopened_files field - Add #[allow(dead_code)] to from_val_simple helper function - Remove unnecessary mut from wasi variable in wasmi build - Add simd feature to Cargo.toml that enables wasmi/simd - Enable simd feature by default in wasmi-runtime The dead code is intentionally kept for future Preview2 component support.

juancastillo0 · 2026-01-30T19:02:06Z

Hi, thank you so much, there are multiple changes, this may take some time.

I was thinking on updating the flutter_rust_bridge dependency. Was that something you tried?
Is cargo kit a copy of the whole repository? shouldn't we depend on it as a package, git fixed dependency or maybe add to git ignore and have a script to clone it locally? I don't think we should copy the whole code into the repo
There are multiple TODOs, which should be handled before merging? should we creare an issue for future improvements?
Did you try the automatic tests of all the other packages like image_ops?
Can't wasm_run_native be implemented in wasm_run? Maybe so that wasm_run_flutter depends on wasm_run which has the native builds?
There seems to be duplicated code on the rust side? there is wasm_run/native and wasm_run_native. Some of the wasm_run_native files do not have the git history, it's kind of hard to see what has changed, even though they should appear as moved on git

juancastillo0 · 2026-01-30T17:16:47Z

    pub fn fuel_consumed(&self) -> SyncReturn<Option<u64>> {
-        self.with_module_mut(|store| SyncReturn(store.fuel_consumed()))
+        // get_fuel returns remaining fuel, not consumed
+        // We can't track consumed fuel without knowing initial fuel
+        self.with_module_mut(|store| SyncReturn(store.get_fuel().ok()))
    }


I think we should track it or perhaps just remove it and increase the version. There are many changes, so I think increasing the version would be better anyway

lukehutch · 2026-01-31T00:27:37Z

Yeah, it's a massive pull request! Sorry about that! But hopefully it saves you a lot of work. I want to see your project succeed as the technology has continued to evolve.

I was thinking on updating the flutter_rust_bridge dependency. Was that something you tried?

That's the one thing I didn't do in this pull request, because it was a very extensive change -- actually Claude recognized what a lot of work it would take, and gave me the option. I said no. But I then went back and I have had Claude working on that in another sub-branch off of the branch that this PR is generated from (it's always annoying to work with two different PRs when there are dependencies between them, but I wanted to keep the bridge changes separate). I'm still working on that, but I will check it in soon, and that change will depend upon this one being committed first.

Is cargo kit a copy of the whole repository? shouldn't we depend on it as a package, git fixed dependency or maybe add to git ignore and have a script to clone it locally? I don't think we should copy the whole code into the repo

I honestly don't know... I know basically nothing about Rust, so I just crossed my fingers that Claude would do the right thing, and I have relied on the unit tests passing, and compilation warnings being fixed, as a validity check.

There are multiple TODOs, which should be handled before merging? should we creare an issue for future improvements?

Which TODOs specifically?

We should get all the modernization work done as a single release, I think... and if it's a single massive merge once everything is working, I think that's OK. You can clone my branch locally to test it out.

Did you try the automatic tests of all the other packages like image_ops?

I asked Claude to ensure that all tests succeeded, but let me double-check that.

Can't wasm_run_native be implemented in wasm_run? Maybe so that wasm_run_flutter depends on wasm_run which has the native builds?

That would also be fine... I'll ask it to make that change.

There seems to be duplicated code on the rust side? there is wasm_run/native and wasm_run_native. Some of the wasm_run_native files do not have the git history, it's kind of hard to see what has changed, even though they should appear as moved on git

OK, I'll have it look at that again too.

lukehutch · 2026-01-31T00:39:58Z

OK, the flutter-rust-bridge upgrade (which is huge) is submitted as a PR.

Oh, I forgot to mention about this PR, upgrading wasmtime: wasmtime supports Preview1 (which is generated by basically all compilers) and Preview2 (which made it into the spec despite a huge amount of infighting, and is not universally supported, because it basically pushes Rust ideology into the wasm philosophy, which is apparently not welcome because it's not general enough). Claude asked me to choose which to support, and I asked it to support both. Preview3 is not widely available now (I think it's in wasmtime, in a preview branch or something), but I put a placeholder in for that.

- Move native platform directories (android, ios, linux, macos, windows) from wasm_run_native into wasm_run - Move cargokit tooling into wasm_run - Update wasm_run_flutter to depend only on wasm_run for native libs - Delete wasm_run_native package (now consolidated) - Fix FFI compatibility issues for newer Dart SDK (3.10.1): - Remove broken 'bool' typedef that shadowed core bool type - Add DartPostCObject typedef for store_dart_post_cobject override - Add @ffi.Bool() annotations to struct bool fields - Add explicit type casts in wire2api functions - Update class references from WasmRunDart to WasmRunNative - Add missing anyRef, exnRef, contRef cases to ValueTy switches - Add uuid dependency required by generated code

- Fix Rust clippy warnings: remove clone on Copy types, use unwrap_or instead of unwrap_or_else, use is_multiple_of, remove needless borrows - Add missing GC type cases (anyRef, eqRef, i31Ref, structRef, arrayRef, exnRef, contRef) to web ValueTy switches for exhaustiveness - Sort dependencies alphabetically in wasm_run_flutter pubspec - Add publish_to: none to wasm_run_flutter since it uses path dependencies

- Add GC type cases (anyRef, exnRef) to wasmi WasmVal::to_value with proper error message that GC types are not supported in wasmi runtime - Update Cargo.toml workspace to use packages/wasm_run/native after merging wasm_run_native into wasm_run package

juancastillo0 · 2026-01-31T01:27:17Z

Thank you so much!
Yeah, the wasmtime and wit stuff was kind of unstable when I implemented it, I checked some months after that and it was still undecided what should be the next steps. I will have to read more to see what is the status and understand the PR.

Can't wasm_run_native be implemented in wasm_run? Maybe so that wasm_run_flutter depends on wasm_run which has the native builds?

I suppose this part is not really necessary. However, they are duplicating code and wasm_run already has some scripts to retrive the compiled artifacts for each platform so one can use them in non-flutter code. The problem is that it isn't using the dart native build steps, that had not been released when I implemented it.

Reading some more about cargokit, I am not sure it's worth it. It does not have recent commits, does not use https://github.com/dart-lang/native and from what I understand it requires rustup? Do you have a requirement to compile locally? Can't it be as it was before with the binary compiled through github actions? Maybe it would be a good option, but it should use the dart native build pipeline and perhaps use rustup through there? I will do more research, but for now I believe it should not be in the repo, maybe have the code in git ignore with a script to retrieve a fixed version of the repo.

- Remove Cargokit directory and all platform-specific build files - Add hook/build.dart for native_toolchain_rust build system - Add native/rust-toolchain.toml with pinned Rust version - Update pubspec.yaml with hooks dependency - Remove ffiPlugin entries from wasm_run_flutter (native assets bundled via hooks) - Update SDK version requirements to 3.6.0+

lukehutch · 2026-01-31T02:04:28Z

OK, so native_toolchain_rust transitively requires a newer flutter_rust_bridge. So I'm going to make all the changes here in this single (massive, sorry) PR...

- Migrated from flutter_rust_bridge v1 to v2.11.1 - Merged wasm_run_native into wasm_run package - Updated Rust code structure for FRB v2 (api/mod.rs, api/wasmtime.rs, api/wasmi.rs) - Replaced bridge_generated.rs with frb_generated.rs - Added new FRB v2 generated Dart files in lib/src/rust/ - Updated Dart FFI layer to use FRB v2 APIs (api() instead of defaultInstance()) - Updated web.dart to use dart:js_interop and web package instead of deprecated dart:js_util - Updated runner_identity to use ExternalLibrary type - Updated hook/build.dart for native_toolchain_rust 1.0.3 API - Upgraded freezed_annotation to ^3.1.0 and freezed to ^3.2.4 - Upgraded very_good_analysis to ^10.0.0 - Updated all example packages to latest SDK versions - Removed obsolete FRB v1 test files (wasmi_test.dart) - Added native_toolchain_rust as dev_dependency for analyzer support

- Upgrade wasm_run/native to Rust 2024 edition with explicit unsafe blocks - Upgrade all WASM packages to Rust 2024 (except rust_threads_example which needs nightly) - Add #![allow(unsafe_op_in_unsafe_fn)] for WIT-generated bindings compatibility - Fix Dart analyzer warnings (unused imports, casts, etc.) - Add Flutter Linux example app for build testing - Configure native_toolchain_rust hook for native assets - Update rust-toolchain.toml with Rust 1.93.0 - Fix DartFormatter languageVersion in dart_wit_component

- Add cross-build.sh script supporting 10 target platforms: * Linux x64 and ARM64 * Android ARM64, ARM32, x64, x86 * macOS x64 and ARM64 (via osxcross Docker) * Windows x64 (GNU toolchain) * iOS ARM64 (with automatic SDK download from GitHub) - Add top-level build.sh for unified project building - Add Cross.toml configuration for cross-rs targets - Update Cargo.toml to disable ittapi profiling for Windows compatibility - Update rust-toolchain.toml with all cross-compilation targets - Add .gitignore entries for build artifacts Features: - Parallel build support with results summary - Automatic iOS SDK download (sparse checkout) on Linux/Windows - Docker image cleanup after builds to save disk space - --clean flag to remove build artifacts

lukehutch · 2026-01-31T10:50:39Z

@juancastillo0 OK, the latest commit moves the build process to native_toolchain_rust, and also upgrades all the code to use flutter_rust_bridge v2.

I also had Claude merge the native builds into wasm_run, and asked Claude to remove code duplication between wasm_run and wasm_run_flutter.

I found a better way to do cross-complilation: https://github.com/cross-rs/cross -- and I asked Claude to get flutter_rust_bridge working with this. I also had to add osxcross to compile the OSX and iOS targets on Linux. It even pulls the iOS SDK from a sketchy repo https://github.com/xybp888/iOS-SDKs on Linux so that you don't have to create an Apple account and download the SDK (all cross-compilation works from Linux). (By the way this sketchy github repo is probably fine to use, because the SDK images there are only used to compile against by the cross-compiler -- the code in the SDK images cannot be run.)

I also updated the Rust code to work with the stricter requirements in the 2024 edition around unsafe (I don't know if any of the code marked unsafe could be or should be made safe, rather than simply be marked as unsafe).

This will need some careful human review, which I'm out of my depth to do, as I'm not a Rust expert... but overall generally for this type of task, Claude Opus doesn't make a whole lot of silly mistakes, and all the tests seem to pass, so it's probably not in bad shape.

- Add custom Dockerfile for cross-rs targets that runs as host user (via CROSS_USER_ID/CROSS_GROUP_ID build args in Cross.toml) - Add fix_target_ownership() for osxcross builds that chowns after build (custom osxcross image approach abandoned due to disk space constraints) - Cross-rs builds (Linux, Android, Windows): files now owned by host user - Osxcross builds (macOS, iOS): files fixed with sudo chown after build

Use chmod -R a+rX on root's rustup/cargo directories to make them accessible to the builder user, rather than copying them (which doubles disk usage during build).

- Use separate target-cross directory for cross-rs builds to avoid GLIBC version conflicts between host-built and container build scripts - Update ownership fix function to handle both target directories - Add target-cross cleanup to build.sh clean command - Document cross-compilation build system in native README.md

lukehutch · 2026-01-31T22:19:52Z

OK, I did a lot of work on the build system, and I think it's probably ready to go at this point. I'll hand it over to you!

- Uses Docker-based cross-compilation via cross-build.sh - Builds all 10 targets (Linux, macOS, iOS, Android, Windows) - Packages libraries in release-friendly tar.gz archives - Triggers on tags or manual workflow dispatch - Can create draft releases for testing

lukehutch · 2026-02-04T05:11:30Z

If you have other large-scale changes you want to make, let me know -- I pay for the max tier of Claude Opus, so I may as well use all my credits every day...

lukehutch added 2 commits January 30, 2026 02:50

juancastillo0 reviewed Jan 30, 2026

View reviewed changes

Migrate to flutter_rust_bridge v2

daebdf1

lukehutch mentioned this pull request Jan 31, 2026

flutter-rust-bridge v2 migration #73

Closed

lukehutch added 3 commits January 30, 2026 17:56

lukehutch added 3 commits January 30, 2026 19:15

lukehutch added 3 commits January 31, 2026 04:25

Simplify Dockerfiles to use chmod instead of cp for rustup

3c0b550

Use chmod -R a+rX on root's rustup/cargo directories to make them accessible to the builder user, rather than copying them (which doubles disk usage during build).

juancastillo0 closed this Apr 9, 2026

juancastillo0 reopened this Apr 9, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrade wasmtime to 41.0.1 and wasmi to 1.0.7#72

Upgrade wasmtime to 41.0.1 and wasmi to 1.0.7#72
lukehutch wants to merge 16 commits into
juancastillo0:mainfrom
lukehutch:upgrade-versions

lukehutch commented Jan 30, 2026

Uh oh!

lukehutch commented Jan 30, 2026

Uh oh!

lukehutch commented Jan 30, 2026

Uh oh!

juancastillo0 commented Jan 30, 2026 •

edited

Loading

Uh oh!

juancastillo0 Jan 30, 2026

Uh oh!

lukehutch commented Jan 31, 2026

Uh oh!

lukehutch commented Jan 31, 2026

Uh oh!

juancastillo0 commented Jan 31, 2026 •

edited

Loading

Uh oh!

lukehutch commented Jan 31, 2026

Uh oh!

lukehutch commented Jan 31, 2026 •

edited

Loading

Uh oh!

lukehutch commented Jan 31, 2026

Uh oh!

lukehutch commented Feb 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

lukehutch commented Jan 30, 2026

Uh oh!

lukehutch commented Jan 30, 2026

Uh oh!

lukehutch commented Jan 30, 2026

Uh oh!

juancastillo0 commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

juancastillo0 Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

lukehutch commented Jan 31, 2026

Uh oh!

lukehutch commented Jan 31, 2026

Uh oh!

juancastillo0 commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lukehutch commented Jan 31, 2026

Uh oh!

lukehutch commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lukehutch commented Jan 31, 2026

Uh oh!

lukehutch commented Feb 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

juancastillo0 commented Jan 30, 2026 •

edited

Loading

juancastillo0 commented Jan 31, 2026 •

edited

Loading

lukehutch commented Jan 31, 2026 •

edited

Loading