| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Move from segment indexes to names. This is a breaking change to make the API more
capable and consistent. An effort has been made to reduce the burden on C API users
where possible (specifically, you can avoid providing names and let Binaryen make them
for you, which will basically be numbers that match the indexes from before).
Fixes #6247
|
| |
|
| |
In the JS API this is optional and it defaults to `funcref`.
|
| |
|
|
|
|
|
|
|
|
|
| |
Passive element segments do not belong to any table, so the link between
Table and elem needs to be weaker; i.e. an elem may have a table in case
of active segments, or simply be a collection of function references in
case of passive/declarative segments.
This PR takes Table::Segment out and turns it into a first class module
element just like tables and functions. It also implements early support
for parsing, printing, encoding and decoding passive/declarative elem
segments.
|
| |
|
|
|
| |
Binaryen.js now uses binaryen (was Binaryen) as its global
name to align with the npm package. Also fixes issues with
emitting and testing both the JS and Wasm builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR enables compiling Binaryen to WebAssembly when building binaryen.js. Since WebAssembly is best compiled and instantiated asynchronously in browsers, it also adds a new mechanism to tell if respectively when the module is ready by means of one of the following:
// Using a promise
const binaryen = require("binaryen");
binaryen.ready.then(() => {
... use normally ...
});
// Using await
const binaryen = require("binaryen");
(async () => {
await binaryen.ready;
... use normally ...
})();
// Where top-level await is available
const binaryen = await require("binaryen").ready;
... use normally ...
One can also tell if Binaryen is already ready (for example when assuming it in follow-up code) by:
if (/* we already know that */ binaryen.isReady) {
... use normally ...
} else {
throw Error("Binaryen is supposed to be ready here but isn't");
}
The JS test cases have been updated accordingly by wrapping everything in a test function and invoking it once ready. Documentation will have to be updated as well to cover this of course. New file size is about 2.5mb, even though the Wasm becomes inlined into the JS file which makes distribution across different environments a lot easier.
Also makes building binaryen (to either js or wasm) emit binaryen.js, and not binaryen_js.js etc.
Supersedes and thus fixes #1381
With .ready it also fixes #2452
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function signatures were previously redundantly stored on Function
objects as well as on FunctionType objects. These two signature
representations had to always be kept in sync, which was error-prone
and needlessly complex. This PR takes advantage of the new ability of
Type to represent multiple value types by consolidating function
signatures as a pair of Types (params and results) stored on the
Function object.
Since there are no longer module-global named function types,
significant changes had to be made to the printing and emitting of
function types, as well as their parsing and manipulation in various
passes.
The C and JS APIs and their tests also had to be updated to remove
named function types.
|
|
|
This PR adds an offset parameter to BinaryenSetFunctionTable so table elements
can start at the value of an (imported constant) global. Previously, the offset
was fixed to zero. As usual this is a breaking change to the C-API but backwards
compatible when using the JS-API.
|
