Open Freax13 opened 4 years ago
the webassembly part of the macro has to be compiled on nightly
Just to clarify: the needs to be compiled with nightly into the binary .wasm
form by the macro maintainer, but the consumer needs no nightly to run it, correct?
correct
@dtolnay ping
I am on board with this but I would prefer to keep a stable workflow available. Do you think it would be possible to feature gate this such that a macro author is able to opt in to either the unstable bridge server or the proc-macro2 patch, according to their environment and preference?
I don't see a reason as to why feature gating wouldn't work. I haven't worked on this for a while, but afaict rn proc-macro hasn't changed that much
@Freax13 in the initial issue text you said you had a demo working, is that demo publicly accessible?
I think I was refering to watts official demo. I probably just switched proc_macro2 to proc_macro and syn::parse2 to syn::parse and used that
I looked at it again and even though I haven't gotten the demo to work again yet I'm confident that I'll get it running again.
For some reason both proc-macro2 and syn seem to disable their proc-macro features on wasm targets. It's pretty easy to fix (I just had to remove the features gates), but those features would have to be re-added (not really a concern yet though, I'm just saying)
I'm pretty much done now. I've implemented the complete proc-macro Server and even got jit working. I'd welcome some feedback.
I'm currently working on a pr that allows proc_macro to run inside webassembly by implementing a
proc_macro::bridge::Server
that forwards all the calls over ffi to the real macro. (I already got the demo working :partying_face: ).Pros:
Cons:
proc_macro::bridge::Server
is unstableSo my question is: Is there a reason why you're not already doing this? I don't want to waste my time on this if that's not even something you might want