This commit updates the threads transformation for LLVM 10 where LLD has
has breaking changes from LLVM 9. While previously the support here
attempted to straddle multiple LLVM styles this is now removed in favor
of simply supporting LLVM 10's style of output. This means that
wasm-bindgen will only be compatible with recent nightlies and forward.
The major change here is that the `__wasm_init_memory` function is
automatically called by the `start` function. We handle that by placing
the previous `start` function first, before stack/tls allocation. Other
changes are to delete all the old code from pre-llvm-9.
Closes#2175
* Enable nested namespace (#951)
* Specify the namespace as array (#951)
* added an example to the document
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
This commit updates the `walrus` crate used in `wasm-bindgen`. The major
change here is how `walrus` handles element segments, exposing segments
rather than trying to keep a contiugous array of all the elements and
doing the splitting itself. That means that we need to do mroe logic
here in `wasm-bindgen` to juggle indices, segments, etc.
* use global import map for rename
* fix same ns import
* cargo fmt
* add basic test
* move generate_identifier, add comments, add tests
* remove leading &mut
* remove unnecessary bail
* use import_name for global and some refine
* Add back in error handling, clean up instruction iteration
* Remove unnecessary patch statements
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* Pre-generating web-sys
* Fixing build errors
* Minor refactor for the unit tests
* Changing to generate #[wasm_bindgen} annotations
* Fixing code generation
* Adding in main bin to wasm-bindgen-webidl
* Fixing more problems
* Adding in support for unstable APIs
* Fixing bug with code generation
* More code generation fixes
* Improving the webidl program
* Removing unnecessary cfg from the generated code
* Splitting doc comments onto separate lines
* Improving the generation for unstable features
* Adding in support for string values in enums
* Now runs rustfmt on the mod.rs file
* Fixing codegen for constructors
* Fixing webidl-tests
* Fixing build errors
* Another fix for build errors
* Renaming typescript_name to typescript_type
* Adding in docs for typescript_type
* Adding in CI script to verify that web-sys is up to date
* Fixing CI script
* Fixing CI script
* Don't suppress git diff output
* Remove duplicate definitions of `Location`
Looks to be a preexisting bug in wasm-bindgen?
* Regenerate webidl
* Try to get the git diff command right
* Handle named constructors in WebIDL
* Remove stray rustfmt.toml
* Add back NamedConstructorBar definition in tests
* Run stable rustfmt over everything
* Don't run Cargo in a build script
Instead refactor things so webidl-tests can use the Rust-code-generation
as a library in a build script. Also fixes `cargo fmt` in the
repository.
* Fixup generated code
* Running web-sys checks on stable
* Improving the code generation a little
* Running rustfmt
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* Create JavaScript array without using `new` keyword.
At present [this line of code](https://github.com/rustwasm/wasm-bindgen/blob/master/crates/cli-support/src/js/mod.rs#L747) creates the heap using JavaScript's new keyword.
```
//Line 747
self.global(&format!("const heap = new Array({});", INITIAL_HEAP_OFFSET));
self.global("heap.fill(undefined);");
```
Assuming that the `INITIAL_HEAP_OFFSET` is always 32 (because it is set as a constant in the Rust code), below is the equivalent of what this code will produce; an Array Object with 32 items which are all undefined.
```
const heap = new Array(32);
//(32) [empty × 32]
//Where
var zero_element = heap[0];
//undefined
var one_element = heap[1];
//undefined
```
I believe that this is the desired outcome for the program. All good.
### Suggestion to consider
I am always reminded **not** to use the `new` keyword. Mainly by reading or listening to JavaScript ["The Good Parts"](https://youtu.be/XFTOG895C7c?t=1654).
For example if the `INITIAL_HEAP_OFFSET` was ever anything but one number, the heap would be created in a different way. For example if two numbers are passed in, then an array of size 2 would be created; where both items in the array are individual numbers.
```
const heap = new Array(32, 32);
var zero_element = heap[0];
var one_element = heap[1];
//32
//32
```
I know that this is highly unlikely, due to the fact that the `INITIAL_HEAP_OFFSET` is set as a `const` in the Rust. But thought that I would put out the following suggestion for consideration anyway. This comes from a place of just wanting to contribute in a way that could make this already awesome program a little better. :)
### Suggested update
The heap array could be created using the following code
```
const heap = [];
heap.length = INITIAL_HEAP_OFFSET;
heap[0]
heap[1]
//undefined
//undefined
```
This would create a JavaScript Array of length `INITIAL_HEAP_OFFSET`, where are items are `undefined`
The new code generates (in raw JavaScript)
```
const heap = [];
heap.length = 32;
```
Which produces
```
(32) [empty × 32]
```
In the same way that the original code does.
* Add closing parenthesis to close out self.global
* Adding files which were altered by the BLESS=1 system variable. Essentially updating generated files that are used for testing.
* Adding code generated wat file, by way of running tests using BLESS=1
* Adding table.wat that was generated by running the tests with BLESS=1 set
* Update code that creates heap array line 747 mod.rs
* Updating files that are automatically generated when using BLESS=1
The main gc pass of unused items in wasm-bindgen was accidentally
removing the function table because we weren't properly rooting it in
the auxiliary section which has a few ways that imports can reference
the function table via intrinsics and closures.
Closes#1967
This commit updates how TypeScript signature are generated from adapters
in wasm-bindgen. A richer set of `AdapterType` types are now stored
which record information about optional types and such. These direct
`AdapterType` values are then used to calculate the TypeScript
signature, rather than following the instructions in an adapter function
(which only works anyway for wasm-bindgen generated adapters).
This should be more robust since it reads the actual true signature of
the adapter to generate the TypeScript signature, rather than attempting
to ad-hoc-ly infer it from the various instructions, which was already
broken.
A number of refactorings were involved here, but the main pieces are:
* The `AdapterType` type is a bit more rich now to describe more
Rust-like types.
* The `TypescriptArg` structure is now gone and instead return values
are directly inferred from type signatures of adapters.
* The `typescript_{required,optional}` methods are no longer needed.
* The return of `JsBuilder::process` was enhanced to return more values,
rather than storing some return values on the structure itself.
Closes#1926
The wasm-bindgen nightly test suite started failing recently and a
bisection shows that rust-lang/rust#67363 is the cause of this issue.
The problem happening here is that after that Rust PR duplicate imports
from the same name/module in different parts of a Rust program may now
show up as duplicate imports rather than being coalesced into one
import. This was tripping up `wasm-bindgen` which, when translating from
the wasm module to wasm-bindgen's IR, is unfortunately very
string-based.
The fix here was to detect these duplicate imports and map them all to
the same item, removing the duplicate imports.
Closes#1929
This commit adds a test suite for consuming interface types modules as
input and producing a JS polyfill output. The tests are relatively
simple today and don't exercise a ton of functionality, but they should
hopefully cover the breadth of at least some basics of what wasm
interface types supports today.
A few small fixes were applied along the way, such as:
* Don't require modules to have a stack pointer
* Allow passing `*.wat`, `*.wit`, or `*.wasm` files as input to
`wasm-bindgen` instead of always requiring `*.wasm`.
* Add tests for the interface types output of wasm-bindgen
This commit expands the test suite with assertions about the output of
the interface types pass in wasm-bindgen. The goal here is to actually
assert that we produce the right output and have a suite of reference
files to show how the interface types output is changing over time.
The `reference` test suite added in the previous PR has been updated to
work for interface types as well, generating `*.wit` file assertions
which are printed via the `wit-printer` crate on crates.io.
Along the way a number of bugs were fixed with the interface types
output, such as:
* Non-determinism in output caused by iteration of a `HashMap`
* Avoiding JS generation entirely in interface types mode, ensuring that
we don't export extraneous intrinsics that aren't otherwise needed.
* Fixing location of the stack pointer for modules where it's GC'd out.
It's now rooted in the aux section of wasm-bindgen so it's available
to later passes, like the multi-value pass.
* Interface types emission now works in debug mode, meaning the
`--release` flag is no longer required. This previously did not work
because the `__wbindgen_throw` intrinsic was required in debug mode.
This comes about because of the `malloc_failure` and `internal_error`
functions in the anyref pass. The purpose of these functions is to
signal fatal runtime errors, if any, in a way that's usable to the
user. For wasm interface types though we can replace calls to these
functions with `unreachable` to avoid needing to import the
intrinsic. This has the accidental side effect of making
`wasm_bindgen::throw_str` "just work" with wasm interface types by
aborting the program, but that's not actually entirely intended. It's
hoped that a split of a `wasm-bindgen-core` crate would solve this
issue for the future.
* Run the wasm interface types validator in tests
* Add more gc roots for adapter gc
* Improve stack pointer detection
The stack pointer is never initialized to zero, but some other mutable
globals are (TLS, thread ID, etc), so let's filter those out.