wasm_bindgen(constructor) doesn't compile with cfg_attr #1191
Comments
|
Oh dear this looks bad! It looks like we're possibly generating bad code and this may not be related to |
|
Sorry for the delay, I made a repo if you'd like to clone and try it out: I built it with |
|
Hm ok thanks for the reproduction! Something is happening here with procedural macros we weren't expecting which is causing the issue. Regardless though this is a use case we want to support! I'll work on getting this fixed hopefully |
|
Ok I think I know how we can solve this. I'm gonna jot some thoughts down so I don't forget! The problem is that in this code: #[foo]
impl Foo {
#[cfg_attr(a, foo)]
pub fn new() {}
}the expansion of the To solve this I think what we should do is expand the above to: impl Foo {
#[cfg_attr(a, foo)]
#[wasm_bindgen_method_of = Foo]
pub fn new() {}
}
// other goop generated by `impl Foo { ... }`basically we rely on recursive macro expansion. We added a synthetic attribute on all methods (at the end). This synthetic attribute will simply return its input if That way when expanding a method we still know whether it's part of a struct or not, and we should properly handle This will be a somewhat involved fix, so it may take some time to implement |
Reported in rustwasm#1191 the fix requires us to get a bit creative I think. The general gist is that a block like this: #[wasm_bindgen] impl Foo { pub fn foo() {} } was previously expanded all in one go. Now, however, it's expanded into: impl Foo { #[__wasm_bindgen_class_marker(Foo = "Foo")] pub fn foo() {} } // goop generated by orginal #[wasm_bindgen] This method of expansion takes advantage of rustc's recursive expansion feature. It also allows us to expand `impl` blocks and allow inner items to not be fully expanded yet, such as still having `#[cfg]` attributes (like in the original bug report). We use theinternal `__wasm_bindgen_class_marker` to indicate that we're parsing an `ImplItemMethod` unconditionally, and then generation proceeds as usual. The only final catch is that when we're expanding in an `impl` block we have to generate tokens for the `Program` (wasm-bindgen injected goop like the custom section) inside the body of the function itself instead of next to it. Otherwise we'd get syntax errors inside of impl blocks! Closes rustwasm#1191
|
Ok a fix should be at #1208! |
Reported in rustwasm#1191 the fix requires us to get a bit creative I think. The general gist is that a block like this: #[wasm_bindgen] impl Foo { pub fn foo() {} } was previously expanded all in one go. Now, however, it's expanded into: impl Foo { #[__wasm_bindgen_class_marker(Foo = "Foo")] pub fn foo() {} } // goop generated by orginal #[wasm_bindgen] This method of expansion takes advantage of rustc's recursive expansion feature. It also allows us to expand `impl` blocks and allow inner items to not be fully expanded yet, such as still having `#[cfg]` attributes (like in the original bug report). We use theinternal `__wasm_bindgen_class_marker` to indicate that we're parsing an `ImplItemMethod` unconditionally, and then generation proceeds as usual. The only final catch is that when we're expanding in an `impl` block we have to generate tokens for the `Program` (wasm-bindgen injected goop like the custom section) inside the body of the function itself instead of next to it. Otherwise we'd get syntax errors inside of impl blocks! Closes rustwasm#1191
Hi, it seems that constructors can't be conditionally tagged when using
cfg_attrin combination withwasm_bindgen(constructor), for example:#[cfg_attr(feature = "bindings", wasm_bindgen(constructor))]The error message I get from attempting this is:
The text was updated successfully, but these errors were encountered: