This commit reimplements how we disambiguate function names on overloading.
Previously functions would be first be disambiguated if they had multiple
instances of the same name, and *then* functions would be disambiguated
aftewards by if their arguments expanded to more than one type to generate.
This commit instead collects everything into one list during the first pass.
This one list contains all signatures known for a given name. Later this list is
walked in one pass to generate all methods necessary, expanding names all at
once instead of two steps.
This should improve the naming of methods across multiple functions which also
have optional arguments. Support in this commit is just enough for namespaces,
but following commits will update the strategy for mixins/interfaces.
Additionally only new code was added in this commit which duplicates a lot of
functionality, but subsequent commits will remove the old code that will
eventually no longer be used.
This commit refactors the lowest-level primitive for creating functions into a
new `create_one_function` function. This doesn't take into account overloading
but is suitable for things like `create_{getter,setter}`. Eventually the
overloading will be implemented in terms of this function.
This commit refactors WebIDL code generation to walk over the fields of
`FirstPassRecord` instead of walking the AST again. This helps remove
redundancies like checking `is_chrome_only` as well as revisiting partial
interfaces and such. This should make it more clear that the first pass's job is
to walk the AST and collect all relevant information, while the codegen pass is
purely about appending items to a `Program`.
Additionally this refactoring will also soon be used to prepare different data
structures for operation overloadings, avoiding the need to walk those ASTs
twice.
This commit adds further support for the `Global` attribute to not only emit
structural accessors but also emit functions that don't take `&self`. All
methods on a `[Global]` interface will not require `&self` and will call
functions and/or access properties on the global scope.
This should enable things like:
Window::location() // returns `Location`
Window::fetch(...) // invokes the `fetch` function
Closes#659
We currently pass a raw view into wasm's memory for `getStringFromWasm`, but if
the memory is actually shared then `TextDecoder` rejects `SharedArrayBuffer` and
won't actually decode anything. Work around this for now with an extra copy into
a local buffer, and then pass that buffer to `getStringFromWasm` whenever memory
is shared.
In addition to closing #495 this'll be useful eventually when instantiating
multiple wasm modules from Rust as you'd now be able to acquire a reference to
the current module in Rust itself.
The default of Rust wasm binaries is to export the memory that they contain, but
LLD also supports an `--import-memory` option where memory is imported into a
module instead. It's looking like importing memory is along the lines of how
shared memory wasm modules will work (they'll all import the same memory).
This commit adds support to wasm-bindgen to support modules which import memory.
Memory accessors are tweaked to no longer always assume that the wasm module
exports its memory. Additionally JS bindings will create a `memory` option
automatically because LLD always imports memory from an `env` module which won't
actually exist.
I discussed this with @fitzgen awhile back and this sort of casting seems
especially problematic when you have code along the lines of:
let mut x: HtmlElement = ...;
{
let y: &mut JsValue = x.as_ref();
*y = 3.into();
}
x.some_html_element_method();
as that will immediately throw! We didn't have a use case for mutable casting
other than consistency, so this commit removes it for now. We can possibly add
it back in later if motivated, but for now it seems reasonable to try to avoid
these sorts of pitfalls!
