Commits on Mar 22, 2018

1. rustc: Add a #[wasm_custom_section] attribute …

   This commit is an implementation of adding custom sections to wasm artifacts in
   rustc. The intention here is to expose the ability of the wasm binary format to
   contain custom sections with arbitrary user-defined data. Currently neither our
   version of LLVM nor LLD supports this so the implementation is currently custom
   to rustc itself.
   
   The implementation here is to attach a `#[wasm_custom_section = "foo"]`
   attribute to any `const` which has a type like `[u8; N]`. Other types of
   constants aren't supported yet but may be added one day! This should hopefully
   be enough to get off the ground with *some* custom section support.
   
   The current semantics are that any constant tagged with `#[wasm_custom_section]`
   section will be *appended* to the corresponding section in the final output wasm
   artifact (and this affects dependencies linked in as well, not just the final
   crate). This means that whatever is interpreting the contents must be able to
   interpret binary-concatenated sections (or each constant needs to be in its own
   custom section).
   
   To test this change the existing `run-make` test suite was moved to a
   `run-make-fulldeps` folder and a new `run-make` test suite was added which
   applies to all targets by default. This test suite currently only has one test
   which only runs for the wasm target (using a node.js script to use `WebAssembly`
   in JS to parse the wasm output).

   

   alexcrichton committed Mar 22, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for 7df6f41
   • Browse repository at this point

   Copy the full SHA

   7df6f41 View commit details

   Browse the repository at this point in the history

2. rustc: Add a #[wasm_import_module] attribute …

   This commit adds a new attribute to the Rust compiler specific to the wasm
   target (and no other targets). The `#[wasm_import_module]` attribute is used to
   specify the module that a name is imported from, and is used like so:
   
       #[wasm_import_module = "./foo.js"]
       extern {
           fn some_js_function();
       }
   
   Here the import of the symbol `some_js_function` is tagged with the `./foo.js`
   module in the wasm output file. Wasm-the-format includes two fields on all
   imports, a module and a field. The field is the symbol name (`some_js_function`
   above) and the module has historically unconditionally been `"env"`. I'm not
   sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd
   like the ability to configure it!
   
   The proposed ES module integration with wasm (aka a wasm module is "just another
   ES module") requires that the import module of wasm imports is interpreted as an
   ES module import, meaning that you'll need to encode paths, NPM packages, etc.
   As a result, we'll need this to be something other than `"env"`!
   
   Unfortunately neither our version of LLVM nor LLD supports custom import modules
   (aka anything not `"env"`). My hope is that by the time LLVM 7 is released both
   will have support, but in the meantime this commit adds some primitive
   encoding/decoding of wasm files to the compiler. This way rustc postprocesses
   the wasm module that LLVM emits to ensure it's got all the imports we'd like to
   have in it.
   
   Eventually I'd ideally like to unconditionally require this attribute to be
   placed on all `extern { ... }` blocks. For now though it seemed prudent to add
   it as an unstable attribute, so for now it's not required (as that'd force usage
   of a feature gate). Hopefully it doesn't take too long to "stabilize" this!
   
   cc rust-lang-nursery/rust-wasm#29

   

   alexcrichton committed Mar 22, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for d889957
   • Browse repository at this point

   Copy the full SHA

   d889957 View commit details

   Browse the repository at this point in the history