koute
Debug builds should work on wasm32-unknown-unknown now
https://github.com/rust-lang-nursery/rust-wasm/issues/1
Hopefully this means cargo-web doesn't need to force release mode anymore.
Any updates on the status of this issue? (The new link is https://github.com/rustwasm/team/issues/1.)
EDIT: Just noticed https://github.com/koute/cargo-web/pull/83, looks like there's something a bit more complicated going on than just the above issue.
@Kwarrtz It's in-progress. I need to switch the js! macro to use custom sections first.
I haven't looked too closely yet, but it seems like procedural macros were fully stabilized in Rust 1.30 so I might be able to fix this soon.
don't really know that much about custom sections in wasm, can I still somehow help with the js! macro?
@ForsakenHarmony I stared to work on this already, however it's currently on the backburner. I haven't yet started on converting the js! macro itself though. (This needs three pieces - support in cargo-web, which I've already done, support in __js_raw_asm! which I've partially done, and support in js! which I haven't started yet.)
That is, we need a procedural macro which will take this:
js!(
console.log( 123, @{variable} );
);
and emit something like this (not exactly, as the js! macro does more stuff, but this is the hard part so it will be easy to convert to what we need in the end):
__js_raw_asm!( r#"console.log( 123, $0 );"#, variable );
Basically, the procedural macro has to take its input (the JS code), stringify it replacing every @{...} with placeholders ($0, $1, $2...), and extract the interpolated expressions itself (in this case the sole variable, but this can be any Rust expression). The hardest part of this is probably parsing arbitrary Rust expressions inside of @{...}. (syn should be able to do it, but I'm not sure if it can easily parse an expression explicitly delimited with a } at the end)
If you have some free time and feel like helping out then you could try your hand at writing such a basic procedural macro (it doesn't have to be actually functional; I can take it from there).
(syn should be able to do it, but I'm not sure if it can easily parse an expression explicitly delimited with a } at the end)
Rather than chopping off the { and then trying to parse up to the }, why not instead just parse the entire {...} expression with syn? Since {} is already an expression (specifically a block expression), it should work.
And then you could do some validation on the AST to ensure that the block expression only contains a single expression inside of it (and no statements).
Alternatively, you could actually allow for statements + multiple expressions inside of @{}, so this would work:
js!(
var x = @{
let y = 10;
y + 20
};
);
@Pauan Yep! Good point. As long as it stringifies the code just as the current js! macro it should be fine.