Haha yeah @davidtolnay told me agput it during RustConf, and so excited about it also!!!
-
-
I'm extremely confused at how wasm affects proc macros
1 reply 0 retweets 4 likes -
We'd like to have http://crates.io distribute proc macros as precompiled wasm binaries that are executed by a wasm runtime in the compiler. Then adding a dependency on a proc macro no longer adds anything to compile time.
4 replies 6 retweets 26 likes -
Interesting. You still have to compile the wasm, so it's not "nothing" ;) Why wasm over MIR or a cranelift based rustc?
1 reply 0 retweets 3 likes -
Replying to @sgrif @davidtolnay and
Wild guess: wasm is stable, MIR is *very* unstable
1 reply 0 retweets 1 like -
Replying to @steveklabnik @davidtolnay and
That's my guess too, but this is executed in the compiler so there's some flexibility -- and there's been talk of MIR only crates for a while now so the idea of making it forwards compatible seems like it's in the realm of possibility anyway
1 reply 0 retweets 2 likes -
Replying to @sgrif @steveklabnik and
My impression is MIR codegen to machine code takes much longer than wasm to machine code, or alternatively interpreted MIR has a 10x or worse performance overhead than wasm. Determinism and isolation are additional advantages over MIR:https://internals.rust-lang.org/t/pre-rfc-procmacros-implemented-in-wasm/10860 …
2 replies 0 retweets 4 likes -
Replying to @davidtolnay @sgrif and
miri is better at determinism and isolation though, its allocations are symbolic, while wasm is concrete in a sense, miri is more objcap than wasm only good reason not to use miri IMO, is interpreting cost could be alleviated by monomorphizing on the fly, but unsure
2 replies 0 retweets 1 like -
I meant: those are advantages over compiled MIR. We don't want to download proc macros as MIR and finish compiling them because no determinism and isolation and it's slow. We don't want to download proc macros as MIR and interpret them because it's slow too.
1 reply 0 retweets 0 likes -
Replying to @davidtolnay @sgrif and
aaah. there is a misunderstanding here, too you couldn't do this even if you wanted to because everything after parsing (macros, types, MIR, etc) depends on the target chosen unless you have .rmeta for a fixed target like wasm32, I guess
2 replies 0 retweets 0 likes
We could if we wanted to, because in practice the overwhelming majority of http://crates.io requests are probably for a pretty small set of targets. You could precompile MIR for those. Perfect shouldn't be the enemy of improving compile time for 99% of users!
-
-
Replying to @davidtolnay @sgrif and
okay, fair, I should've phrased it better for interpretation the target doesn't matter anyway, have you considered dependency on compiler version? with some tweaks to the proc_macro<->rustc bridge you would never need to recompile a wasm blob (except for perf wins etc.)
1 reply 0 retweets 0 likes -
Replying to @eddyb_r @davidtolnay and
this is not true for Cranelift IR, MIR (.rmeta really, MIR isn't an IR that can live outside of rustc's def/type/trait-system) etc. also: have you considered doing the same with build scripts (that don't themselves link against native libraries)? is WASI enough?
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.