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.

Author: warpfork

README.md

@@ -31,6 +31,43 @@ Expect development to prioritize things that are on the path to protocol design
 (Codecs are a SMOP.  An important one, but a relatively well-known space.  We can do those later without a serious risk of problematic unanticipated design feedback cycle.)
 
 
+Building
+--------
+
+This project uses a LOT of tooling from various sources.
+The setup may be nontrivial.
+
+### for tree-sitter
+
+There's a tree-sitter CLI tool; you'll need that to compile the grammar
+and generate the parser (which comes out as a C file).
+
+And to use that parser, you'll probably need `clang` on your path,
+since it's a C file we're talking about.
+
+### for the wasm and web stuff
+
+For this, you'll need a **rust nightly**.
+(This is because we need the `-Zwasm-c-abi=spec` flag;
+without it, wasm'ify'd rust can't call wasm'ify'd C correctly.
+To the best of my knowledge, there's simply no way to address this
+aside from going to a nightly rust.)
+
+And you'll need the wasm-pack tool.  That's fairly easy to get:
+
+```
+cargo install wasm-pack
+```
+
+And you'll need your rust install to have the materials for wasm targets.
+The `wasm-pack` tool will either get that for you automatically (if you used `rustup`),
+or offer you instructions to follow if you need to do it manually.
+
+And you'll also still need clang.
+And probably a fairly recent version: it needs to have wasm32 support,
+and needs to be in reasonable alignment to what rust's wasm stuff is expecting.
+
+
 License
 -------
 

web/.cargo/config.toml

@@ -0,0 +1,2 @@
+[target.wasm32-unknown-unknown]
+rustflags = ["-C", "target-feature=+bulk-memory", "-Zwasm-c-abi=spec"]