Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
it's alive! a walk of the ast alerts in the browser. amaze.
This... finally breaks down and requires rust nightly. I've been going to considerable lengths to try to avoid this, but... I earnestly don't think shipping C+Rust to wasm is possible without it. The main new thing here is the "-Zwasm-c-abi=spec" flag. As described in the README diff, it's essential for rust to call into C correctly when both are wasm'd. (It's beyond me why any other mode exists, but I'll... attempt to bite my tongue.) This critical flag was introduced in rust-lang/rust#117919 . Which describes it as "perma-unstable". And gosh I hope that's not actually going to be true... because again, this seems to be flat out *required* for Rust and C to play together in wasm. And also because "perma-unstable" is just a deeply silly concept, period, context-free. I do not understand any possible reason to want to push people *permanently* towards using "unstable" "nightly" compilers. I don't understand how this needs to be said, but creating a situation where the words "permanently unstable" go together is a Bad Idea. Anyway. The "target-feature=+bulk-memory" flag also comes along because without that, we get a "Uncaught RangeError: Maximum call stack size exceeded" error at runtime. It's attributed to "core::intrinsics::copy::precondition_check" called from "memmove". (That doesn't make a ton of sense to me, looking at the code, but... a lot of things don't make sense to me, looking at any of this; add it to the pile.) Whatever the reason, this flag makes it go. And now it's alive. It's taken days. But hello world has landed. Hooray.
- Loading branch information