Wasm-bindgen: Allow JS functions to be imported inside of non-public modules

Created on 18 May 2018  路  3Comments  路  Source: rustwasm/wasm-bindgen

I wanted to access the JS console as console::log, so I attempted this:

#![feature(proc_macro, wasm_custom_section, wasm_import_module)]

extern crate wasm_bindgen;

mod console {
    use wasm_bindgen::prelude::*;

    #[wasm_bindgen]
    extern {
        #[wasm_bindgen(js_namespace = console)]
        pub fn log(s: &str);
    }
}

The compiler had this warning:

   Compiling imaj v0.1.0 (file:///private/tmp/imaj)
warning: function is marked #[no_mangle], but not exported
  --> src/lib.rs:12:5
   |
12 |     #[wasm_bindgen]
   |     ^^^^^^^^^^^^^^^
   |
   = note: #[warn(private_no_mangle_fns)] on by default

And wasm-bindgen had this to say:

$ wasm-bindgen target/wasm32-unknown-unknown/release/imaj.wasm --out-dir=.
thread 'main' panicked at 'failed to run export: Function("Module doesn\'t have export __wbindgen_describe___wbg_f_log_log_n")', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Making the console module public worked, but it wasn't my goal to make it public.

  • rustc 1.27.0-nightly (acd3871ba 2018-05-10)
  • wasm-bindgen 0.2.10

See also #159

Most helpful comment

I've started a branch at https://github.com/rustwasm/wasm-bindgen/tree/used to game out the usage of #[used] to hopefully overcome the restrictions here, although it's not quite working yet and I haven't had a chance to dig in

All 3 comments

I unfortunately don't know of a great way to solve this, but if anyone else knows how to work around this I'd be more than willing to implement a solution!

I've started a branch at https://github.com/rustwasm/wasm-bindgen/tree/used to game out the usage of #[used] to hopefully overcome the restrictions here, although it's not quite working yet and I haven't had a chance to dig in

Ok I've ironed out various kinks in the branch and it looks like two more things are still needed to implement this:

  1. First we need to upgrade LLD with --gc-sections. Otherwise the binaries keep too much information (a bunch of function pointers). Without --gc-sections we can't turn this on by default as it'll regress wasm sizes too much.
  2. Second, it doesn't actually work! As we can see on the playground the functions are kept in the IR long enough to reach the linker, but they don't persist beyond that. The function is marked as internal when we want it not marked as internal, it needs to be a fully exported function. In that sense we don't have control over linkage visibility in stable Rust, so we'd need another strategy to pursue to get this working.
Was this page helpful?
0 / 5 - 0 ratings

Related issues

arilotter picture arilotter  路  3Comments

hunterlester picture hunterlester  路  4Comments

NateLing picture NateLing  路  3Comments

d3lm picture d3lm  路  3Comments

fitzgen picture fitzgen  路  3Comments