These missing includes were not a problem in our standard build configuration,
but were breaking other build configurations.

Simplify the monotone analyzer by replacing all the state it used to store in
`BlockState` with a simple vector of lattice elements. Use simple indices to
refer to both blocks and their associated states in the vector. Remove the
ability for transfer functions to control the initial enqueued order of basic
blocks since that was a leaky abstraction. Replace the worklist with a
UniqueDeferredQueue since that has generally proven to be more efficient in
smiilarly contexts, and more importantly, it has a nicer API. Make miscellaneous
simplifications to other code as well.

Delete a few unit tests that exposed the order in which blocks were analyzed
because they printed intermediate results. These tests should be replaced with
tests of analyses' public APIs in the future.

… lattice (WebAssembly#6035)

In general, the operation of taking the least upper bound of two lattice
elements may depend on some state stored in the lattice object rather than in
the elements themselves. To avoid forcing the elements to be larger and more
complicated in that case (by storing a parent pointer back to the lattice), move
the least upper bound operation to make it a method of the lattice rather than
the lattice element. This is also more consistent with where we put e.g. the
`compare` method.

While we are at it, rename `makeLeastUpperBound` to `join`, which is much
shorter and nicer. Usually we avoid using esoteric mathematical jargon like
this, but "join" as a normal verb actually describes the operation nicely, so I
think it is ok in this case.

This is a lattice with two elements: `false` is bottom and `true` is top.

Add a new gtest file for testing lattices.

Implement a generic lattice template for integral types ordered by `<`.

…y#6038)

The FullLattice concept extends the base Lattice with `getTop` and `meet`
operations. The `Inverted` lattice uses these operations to reverse the order of
an arbitrary full lattice, for example to create a lattice of integers ordered
by `>` rather than by `<`.

Given a type `T`, `Flat<T>` is the lattice where none of the values of `T` are
comparable except with themselves, but they are all greater than a common bottom
element not in `T` and less than a common top element also not in `T`.

Followup to WebAssembly#6048, we did not handle nondefaultable tuples because of this.

This lattice "lifts" another lattice by inserting a new bottom element
underneath it.

Apparently the version of node on the Alpine runner was updated and no longer
recognizes the --experimental-wasm-threads option. Delete this option out of the
test that was using it.

…y#6053)

Closed-world mode allows function types to escape if they are on exported functions,
because that has been possible since wasm MVP and cannot be avoided. But we need to
also allow all types in those type's rec groups as well. Consider this case:

(module
 (rec
  (type $0 (func))
  (type $1 (func))
 )
 (func "0" (type $0)
  (nop)
 )
 (func "1" (type $1)
  (nop)
 )
)

The two exported functions make the two types public, so this module validates in
closed world mode. Now imagine that metadce removes one export:

(module
 (rec
  (type $0 (func))
  (type $1 (func))
 )
 (func "0" (type $0)
  (nop)
 )
 ;; The export "1" is gone.
)

Before this PR that no longer validates, because it only marks the type $0 as public.
But when a type is public that makes its entire rec group public, so $1 is errored on.

To fix that, this PR allows all types in a rec group of an exported function's type, which
makes that last module validate.

Implement new `RandomLattice` and `RandomFullLattice` utilities that are
lattices randomly created from other lattices. By recursively using themselves
as the parameter lattices for lattices like `Inverted` and `Lift`, these random
lattices can become arbitrarily nested.

Decouple the checking of lattice properties from the checking of transfer
function properties by creating a new, standalone `checkLatticeProperties`
function.

…mbly#6051)

If there are newlines in the list, then we split using them in a simple manner
(that does not take into account nesting of any other delimiters).

Fixes WebAssembly#6047
Fixes WebAssembly#5271

…ly#6056)

Since these methods, which operate on lattice elements, moved to the lattice
types, it no longer makes much sense for their parameters to be called `self`
and `other`. Rename them to `joinee` and `joiner` for joins and `meetee` and
`meeter` for meets.

The elements of `Array<L, N>` lattice are arrays of length `N` of elements of
`L`, compared pairwise with each other. This lattice is a concrete
implementation of what would be written L^N with pen and paper.

The vector lattice is nearly identical to the array lattice, except that the
size of the elements is specified at runtime when the lattice object is created
rather than at compile time. The code and tests are largely copy-pasted and
fixed up from the array implementation, but there are a couple differences.
First, initializing vector elements does not need the template magic used to
initialize array elements. Second, the obvious implementations of join and meet
do not work for vectors of bools because they might be specialized to be bit
vectors, so we need workarounds for that particular case.

This lattice combines any number of other lattices into a single lattice whose
elements are tuples of elements of the other lattices. This will be one of the
most important lattices in the analysis framework because it will be used to
combine information about different parts of the program, e.g. locals and the
value stack, into a single lattice.

…ly#6061)

In particular, if the body just calls another "once" function, then we can
skip the early-exit logic.

Followup to WebAssembly#6061

Add a lattice that is a thin wrapper around `wasm::Type` giving it the interface
of a lattice. As usual, `Type::unreachable` is the bottom element, but unlike in
the underlying API, we uniformly treat `Type::none` as the top type so that we
have a proper lattice.

Many of the lattice tests were essentially copy-pasted from one lattice to the
next because they all tested isomorphic subsets of the various lattices,
specifically in the shape of a diamond. Refactor the code so that all lattices
that have tests of this shape use the same utility test functions.

We handled references but not tuples in one place.

…4 argument (WebAssembly#6074)

In wasm64, function pointers are 64-bit like all pointers.

fixes WebAssembly#6073

…6072)

Previously the fuzzer never added gets or sets of globals from initial content. That was
an oversight, I'm pretty sure - it's just that the code that sets up the lists from which we
pick globals for gets and sets was in another place. That is, any globals in the initial
content file were never used in new random code the fuzzer generates (only new
globals the fuzzer generated were used there).

This PR allows us to use those globals, but also ignores them with some probability,
to avoid breaking patterns like "once" globals (that we want to only be used from
initial content, at least much of the time).

Also simplify the code here: we don't need isInvalidGlobal just to handle the hang
limit global, which is already handled by not being added to the lists we pick names
from anyhow.

…bly#6067)

The analysis framework stores a separate lattice element for each basic block
being analyzed to represent the program state at the beginning of the block.
However, in many analyses a significant portion of program state is not
flow-sensitive, so does not benefit from having a separate copy per block. For
example, an analysis might track constraints on the types of locals that do not
vary across blocks, so it really only needs a single copy of the constrains for
each local. It would be correct to simply duplicate the state across blocks
anyway, but it would not be efficient.

To make it possible to share a single copy of a lattice element across basic
blocks, introduce a `Shared<L>` lattice. Mathematically, this lattice represents
a single ascending chain in the underlying lattice and its elements are ordered
according to sequence numbers corresponding to positions in that chain.
Concretely, though, the `Shared<L>` lattice only ever materializes a single,
monotonically increasing element of `L` and all of its elements provide access
to that shared underlying element.

`Shared<L>` will let us get the benefits of having mutable shared state in the
concrete implementation of analyses without losing the benefits of keeping those
analyses expressible purely in terms of the monotone framework.

Remove the ability to represent the top element of the stack lattice since it
isn't necessary. Also simplify the element type to be a simple vector, update
the lattice method implementations to be more consistent with implementations in
other lattices, and make the tests more consistent with the tests for other
lattices.

…mbly#6071)

Previously, modifying a single vector element of a `Shared<Vector>` element
required materializing a full vector to do the join. When there is just a single
element to update, materializing all the other elements with bottom value is
useless work. Add a `Vector<L>::SingletonElement` utility that represents but
does not materialize a vector with a single non-bottom element and allow it to
be passed to `Vector<L>::join`. Also update `Shared` and `Inverted` so that
`SingletonElement` joins still work on vectors wrapped in those other lattices.

…ly#6077)

Combine the `transfer` and `getDependents` methods of a transfer function so
that a transfer function only has to implement `transfer`, which now returns a
range of basic blocks that may need to be re-analyzed.

To make it easier to implement the returned basic block range, change the
requirement so that it provides iterators to `const BasicBlock*` rather than
`BasicBlock`. This allows us to entirely remove cfg-impl.h.

Helps WebAssembly#5951

Previously CFGWalker designated a particular block as the "exit" block, but it
was just the block that happened to appear at the end of the function that
returned values by implicitly flowing them out. That exit block was not tied in
any way to other blocks that might end in returns, so analyses that needed to
perform some action at the end of the function would have had to perform that
action at the end of the designated exit block but also separately at any return
instruction.

Update CFGWalker to make the exit block a synthetic empty block that is a
successor of all other blocks tthat implicitly or explicitly return from the
function in case there are multiple such blocks, or to make the exit block the
single returning block if there is only one. This means that analyses will only
perform their end-of-function actions at the end of the exit block rather than
additionally at every return instruction.

Update the C++20 builder to use Ubuntu 20.04 to catch problems building with its
system compiler. Also fix such a problem in wasm-fuzz-lattices.cpp.

To support parsing calls, add support for parsing function indices and building
calls with IRBuilder.

)

LocalCSE is nice for large expressions, but for small things it has always been of
unclear benefit since VMs also do GVN/CSE anyhow. So we are likely not speeding
anything up, but hopefully we are reducing code size at least. Doing LocalCSE on
something small like a global.get is very possibly going to increase code size,
however (since we add a tee, and since the local gets are of similar size to global
gets - depends on LUB sizes). On real-world Java code that overhead is noticeable,
so this PR makes us more careful, and we skip things of size 1 (no children).

…opt (WebAssembly#6088)

Because we currently strip some data segments (i.e. EM_JS strings)
during `--post-emscripten` this is too late as `--separate-data-segments`
always runs in `wasm-emscripten-finalize`.

Once emscripten switches over to using the pass directly we can remove
the support from `wasm-emscripten-finalize`

…mbly#6080)

This new optimization will eventually weaken casts by generalizing (i.e.
un-refining) their output types. If a cast is weakened enough that its output
type is a supertype of its input type, the cast will be able to be removed by
OptimizeInstructions.

Unlike refining cast inputs, generalizing cast outputs can break module
validation. For example, if the result of a cast is stored to a local and the
cast is weakened enough that its output type is no longer a subtype of that
local's type, then the local.set after the cast will no longer validate. To
avoid this validation failure, this optimization would have to generalize the
type of the local as well. In general, the more we can generalize the types of
program locations, the more we can weaken casts of values that flow into those
locations.

This initial implementation only generalizes the types of locals and does not
actually weaken casts yet. It serves as a proof of concept for the analysis
required to perform the full optimization, though. The analysis uses the new
analysis framework to perform a reverse analysis tracking type requirements for
each local and reference-typed stack value in a function.

Planned and potential future work includes:

 - Implementing the transfer function for all kinds of expressions.
 - Tracking requirements on the dynamic types of each location to generalize
   allocations as well.
 - Making the analysis interprocedural and generalizing the types of more
   program locations.
 - Optimizing tuple-typed locations.
 - Generalizing only those locations necessary to eliminate at least one cast
   (although this would make the anlysis bidirectional, so it is probably better
   left to separate passes).

…ractions with a parent (WebAssembly#6089)

We had a simple rule that if we reach an expression twice then we give up, which makes
sense for say a block: if one allocation flows out of it, then another can't - it would get
mixed in with the other one, which is a case we don't optimize. However, there are
cases where a parent has multiple children and different interactions with them, like
a struct.set: the reference child does not escape, but the value child does. Before this
PR if we reached the value child first, we'd mark the parent as seen, and then the reference
child would see it isn't the first to get here, and not optimize.

To fix this, reorder the code to handle this case. The manner of interaction between the
child and the parent decides whether we mark the parent as seen and to be further
avoided.

Noticed by the determinism fuzzer, since the order of analysis mattered here.

…embly#6092)

Also add testcases to be comprehensive and notice changes if we ever decide to
modify that behavior.

…ssembly#6095)

The new wat parser parses block, if, loop, then, and else keywords directly
rather than depending on code generated from gen-s-parser.py. Filter these
keywords out in gen-s-parser.py when generating the new wat parser and delete
the stub functions that the removed generated code used to depend on.

Class template argument deduction (CTAD) is a C++17 feature that allows
variables to be declared with class template types without specifying the
template parameters. Deduction guides are a mechanism by which template authors
can control how the template parameters are inferred when CTAD is used. The
Google style guide prohibits the use of CTAD except where template authors opt
in to supporting it by providing explicit deduction guides. For compatibility
with users adhering to Google style, set the compiler flag to check this
condition and add the necessary deduction guides to make the compiler happy
again.

Adds an outlining pass that performs outlining on a module end to end, and two tests.

…sembly#6115)

We had an assert there that was wrong. In fact the assert is just in one of two code paths,
and an optional one: the end situation is we have an expression and a constant to add to it,
and the assert was in the case that the expression is a Const so we can do the add at
compile time (the other code path does the add at runtime). This code path is optional as
Precompute would do such compile-time addition anyhow, but it is nice to fix and leave that
path so that this pass emits fully optimal code.

This is not needed in GUFA as it tracks local values precisely (each set is connected to
the gets that actually read from it), but in a future PR it will be useful to track local
values per index (each set is connected to all gets for that index, i.e., each local index
is a single "location").

Allow outlining to be excluded from the command line on non-Emscripten builds.

Avoid some common warnings and stop printing various stdout/stderr stuff.

Helps WebAssembly#6104

Also mark array.new_elem as unimplemented as a drive-by; it previously had an
incorrect implementation.

…embly#6122)

call.without.effects implies a call to the function reference in the last parameter,
so the values sent in the other parameters must be taken into account when
computing LUBs for refining arguments, otherwise we might refine so much that
the intrinsic call no longer validates.

Finish the transfer functions for all expressions except for string
instructions, exception handling instructions, tuple instructions, and branch
instructions that carry values. The latter require more work in the CFG builder
because dropping the extra stack values happens after the branch but before the
target block.

This implements an idea I mentioned in the past, to extract the subtyping discovery
code out of Unsubtyping so it could be reused elsewhere. Example possible uses:
the validator could use to remove a lot of code, and also a future PR of mine will
need it. Separately from those, I think this is a nice refactoring as it makes Unsubtyping
much smaller.

This just moves the code out and adds some C++ template elbow grease as needed.

Checking a couple of testing TODOs off and adding more tests of the outlining pass for outlining:
- a sequence at the beginning of an existing function
- a sequence that is outlined into a function that takes no arguments
- multiple sequences from the same source function into different outlined functions

Besides If, no control flow structure consumes values from the stack. Fix a
bug in IRBuilder that was causing it to pop control flow children. Also fix a
follow on bug in outlining where it did not make the If condition available on
the stack when starting to visit an If. This required making push() part of
the public API of IRBuilder.

As a drive-by, also add helpful debug logging to IRBuilder.

Co-authored-by: Ashley Nelson <[email protected]>

Seems to fix WebAssembly#6116

Adds tests that ensure outlining is skipping repeat sequences that include local.get, local.set, br, and return instructions.

Adds two tests, creates an outlined function that returns a single value and creates an outlined function that returns multivalue.

)

Adds support for call_indirect to wasm-ir-builder. Tests this works by outlining a sequence including call_indirect.

When branches target control flow structures other than blocks or loops, the
IRBuilder wraps those control flow structures with an extra block for the
branches to target in Binaryen IR. Usually that block has the same type as the
control flow structure it wraps, but when the control flow structure is
unreachable because all its bodies are unreachable, the wrapper block may still
need to have a non-unreachable type if it is targeted by branches.

Previously the wrapper block would also be unreachable in that case. Fix the bug
by tracking whether the wrapper block will be targeted by any branches and use
the control flow structure's original, non-unreachable type if so.

Also fix the parser to correctly error if an imported item appears after a
non-imported item and make the corresponding fix to the test.

…ly#6091)

See WebAssembly#6088

* No `SINGLE_FILE` when building for browser
* Ensure `STACK_SIZE` is big enough
* Fix indentation

…bAssembly#6132)

Asyncify gained a way to wrap a pass so that it only runs on a given set of
functions, rather than on all functions, so the wrapper "filters" what the pass
operates on. That was useful in Asyncify as we wanted to only do work on
functions that Asyncify actually instrumented.

There is another place in the code that needs such functionality,
optimizeAfterInlining, which runs optimizations after we inline; again, we
only want to optimize on the functions we know are relevant because they
changed. To do that, move that logic out to a general place so it can be
reused. This makes the code there a lot less hackish.

While doing so make the logic only work on function-parallel passes. It
never did anyhow, but now it asserts on that. (It can't run on a general
pass because a general one does not provide an interface to affect which
functions it operates on; a general pass is entirely opaque in that way.)

…#6137)

Fixes WebAssembly#6136

Parse the legacy v3 syntax for try/catch/catch_all/delegate in both its folded
and unfolded forms.

The first sources of significant complexity is the optional IDs after `catch`
and `catch_all` in the unfolded form, which can be confused for tag indices and
require backtracking to parse correctly.

The second source of complexity is the handling of delegate labels, which are
relative to the try's parent scope despite being parsed after the try's scope
has already started. Handling this correctly requires punching a whole big
enough to drive a truck through through both the parser and IRBuilder
abstractions.

Avoid adding suffixes when we don't need them to keep names unique.

As background, the suffixes are not used by emcc at all, so they are just
for internal use in the tool. How that works is that metadce gets as input
the list of things the user cares about, with names for them, so it knows
the proper names to give imports and exports, and makes up names for
other things. Those made up names will not be read by the user, so we
can make them prettier as this PR does without breaking anything.

The main benefit of this PR is to make debugging easier.

Remove hardcoded paths for globals/functions/etc. in favor of general code
paths that support all the module elements uniformly. As a result of that, we
now support all parts of wasm, such as tables and element segments, that
we didn't before.

This refactoring is NFC aside from adding functionality. Note that this reduces
the size of wasm-metadce by 10% while increasing its functionality - the
benefits of writing generic code.

To support this, add some trivial generic helpers to get or iterate over module
elements using their kind in a dynamic manner. Using them might make
wasm-metadce slightly slower, but I can't measure any difference.

A trivial call is something like a function that just calls another immediately,

function foo(x, y) {
  return bar(y, 15);
}

We can inline those and expect to benefit in most cases, though we might
increase code size slightly. Hence it makes sense to inline such cases, even
though in general we are careful and do not inline functions with calls in
them; a "trampoline" like that likely has most of the work in the call itself,
which we can avoid by inlining.

Suggested based on findings in Java.

…ame (WebAssembly#6146)

Any function can now be annotated as not to be inlined fully (normally) or not to be
inlined partially. In the future we'll want to read those annotations from the proposed
wasm metadata section on code hints, and from wat text as well, but for now add
trivial passes that set those fields based on function name wildcards, e.g.:

--no-inline=*leave-alone* --inlining

That will not inline any function whose name contains "leave-alone" in the name.

--no-inline disables all inlining (full or partial) while --no-full-inline and
--no-partial-inline affect only full or partial inlining.

These module fields are especially complex to parse because they contain both
nontrivial types and instructions, so their parsing logic needs to be spread out
across the ParseDecls, ParseModuleTypes, and ParseDefs phases of parsing. This
applies to in-line elements in table definitions as well, which means we need to
be able to match a table to its in-line element segment across multiple phases.

Changes the controlFlowQueue used in stringify-walker to push values of Expression*,  This ensures that we walk the Wasm module in the same order, regardless of whether the control flow expression is outlined.

Reviewers: tlively

Reviewed By: tlively

Pull Request: WebAssembly#6139

- Change outlining debug logs to use std::cerr
- Add controlFlowQueue push log
- Fix build error with wasm-ir-builder log's use of ShallowExpression

Reviewers: tlively

Reviewed By: tlively

Pull Request: WebAssembly#6140

Adds support for the loop instruction to be outlined and a test showing a repeat loop being outlined.

Reviewers: tlively

Reviewed By: tlively

Pull Request: WebAssembly#6141

Mixes up the number of results, params, and operands used in
call_indirect instructions that are outlined. Also adds a function
identifier to the original call_indirect test to improve test output
readability.

Reviewers: tlively

Reviewed By: tlively

Pull Request: WebAssembly#6152

)

…y#6157)

Emscripten sets that itself these days.

Here 'basic' tests means that what we have in `binaryen/test/`. We checked
three things with those tests:
- Run `wasm-opt -all -g` on it and compare the output with `*.from-wast`
- Run `wasm-as -all -g` and `wasm-dis` on it and compare the output with
  `*.fromBinary`.
- Run `wasm-as -all` and `wasm-dis` on it and compare the output with
  `*.fromBinary.noDebugInfo`.

I planned to move those to `test/lit/`. But `test/lit/` has other kind of
tests as well, so I think it'd be nice to have a dedicated directory for
these tests.

Before doing that, I noticed there are already four tests that have been
already ported to do this, and this PR moves them to `test/lit/basic/`.

I couldn't come up with a better name than `basic`. If you have other
suggestions please let me know.

At the Oct hybrid CG meeting, we decided to add back `exnref`, which was
removed in 2020:
https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-10.md

The new version of the proposal reflected in the explainer:
https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md

While adding support for `exnref` in the current codebase which has all
GC subtype hierarchies, I noticed we might need `noexn` heap type for
the bottom type of `exn`. We don't have it now so I just set it to 0xff
for the moment.

Something changed in how CI sets up Python and now this is needed to avoid an error.

Currently `get_tests` returns files and directories, especially when
the extension is not given. This makes `get_tests` return a directory
like `test/wasm2js/` as a test.

`wasm2js.py`'s `check_for_stale_files` errors out when there are files
within `test/wasm2js/` whose basenames don't match any files within any
of `test/`, `test/spec/`, `test/wasm2js/`.
https://github.com/WebAssembly/binaryen/blob/1d615b38dd4152494d2f4d3520c8b1d917624a30/scripts/test/wasm2js.py#L33-L46

`wasm2js.wast.asserts` is apparently a special case for asserts test:
https://github.com/WebAssembly/binaryen/blob/1d615b38dd4152494d2f4d3520c8b1d917624a30/scripts/test/wasm2js.py#L28
and this doesn't seem to have the matching `wast` tests in the three
test directories. But it just happened to not error out because
`get_tests` returns directory names too and one of them was `wasm2js`
(`test/wasm2js/` directory).

This makes `get_tests` return only files, and make files in
`assert_tests` not error out additionally.

`wasm2js.asserts.js` and `wasm2js.traps.js` seem to be used in wasm2js
asserts test:
https://github.com/WebAssembly/binaryen/blob/1d615b38dd4152494d2f4d3520c8b1d917624a30/scripts/test/wasm2js.py#L28
https://github.com/WebAssembly/binaryen/blob/1d615b38dd4152494d2f4d3520c8b1d917624a30/scripts/test/wasm2js.py#L126-L127

But other `*.js` tests in `test/` don't seem to be used anywhere. Please
let me know if they are actually being used.

This moves `wasm2js.asserts.js` and `wasm2js.traps.js`, which are only
used in wasmjs tests, to `test/wasm2js/`, and deletes all other `*.js`
tests in `test/`.

We don't have `*.fromasm` files anymore. Also `BIN_DIR` and
`WATERFALL_BUILD_DIR` variables don't seem to be used as well.

This tweaks generated file names and `filecheck` prefixes to be more
(IMHO) consistent. Also shortened binary/BINARY to bin/BIN for
conciseness. This also changes the order of `RUN` commands a little.

And this changes
```console
wasm-opt %t.wast -all -o %t.text.wast -g -S
```
to
```console
wasm-opt %s -all -o %t.text.wast -g -S
```
The current command doesn't take the source file but the generated file
from the command above `wasm-dis`, which is not the behavior of
`check.py`. This changes it back to the original source (`%s`).

As a result of `wasm-opt` change, some tests are now failing because of
the order of `(type)`s. So I just deleted all `CHECK` lines and
regenerated them using `update_lit_checks.py --all-items`. The large
amount of `CHECK` line changes are mainly because I moved `CHECK-TEXT`
before `CHECK-BINARY` and not meaningful.

I tried to exclude wasm2js asserts tests from `check_for_stale_files` in
 WebAssembly#6164, but ended up doing it incorrectly. The file I checked for was
`wasm2js.wast.asserts`, while the output I should have excluded was
`wasm2js.asserts.js`. This fixes the code so we now check the prefix and
not the filename.

…Assembly#6166)

Currently the legacy GC encoding's nullexternref encoding overlaps with
exnref's. We assume the legacy GC encoding won't be used with the exnref
for the moment and assign a random value to it to prevent the clash.

)

Those fields should be copied together with all the rest of the metadata that
already is. This was just missed in the prior PR.

This PR creates a new pass to optimize J2CL specific patterns
that would otherwise difficult to recognize/prove generically
by other binaryen passes.

The pass currently handles fields what we call as "constant-like".
These fields are fields initialized once and unconditionally through
"clinit" function and technically they do have 2 observable states;
 - initial null/0 state
 - initialized state.
However you can only observe initial null/0 state in contrived examples,
not in real world/correct applications.

This pass moves such "clinit" initialized fields to global initialization.

Above pattern also matches other lazy init construct like String and Class
literals (which binaryen already reduces to constant expressions). So
the pass is generalized to include them as well. (by matching any functions
with the name pattern "_@once_")

In order for this pass to be effective:
1. It needs to run between O3 passes
2. We need to stop inlining of "once" functions.

Stopping inlining of the once functions are important to preserve their
structure. This both helps existing OnceReducer pass and new J2CL pass to
be a lot more effective. Also it is not useful to inline these functions
as by defintion they only executed once. This could be achieved by passing
no-inline filter.

Although the inlining is generally disabled for these functions, it is
still needed for some cases since inliner is effectively responsible for
removal of the once functions that are simplified into empty or simple
delegating functions. For this reason, the pass will rename such trivial
function so no-inline filter will no longer match them.

Also note that after all optimizations completed, it does make sense to
have a final stage where the "partial inline" of all once functions are
allowed. This will speed them up by moving the initialization check to
call-site.

Previously, the number of tuple elements was inferred from the number of
s-expression children of the `tuple.make` expression, but that scheme would not
work in the new wat parser, where s-expressions are optional and cannot be
semantically meaningful.

Update the text format to take the number of tuple elements (i.e. the tuple
arity) as an immediate. This new format will be able to be implemented in the
new parser as follow-on work.

We previously overloaded `drop` to mean both normal drops of single values and
also drops of tuple values. That works fine in the legacy text parser since it
can infer parent-child relationships directly from the s-expression structure of
the input, so it knows that a drop should drop an entire tuple if the
tuple-producing instruction is a child of the drop. The new text parser,
however, is much more like the binary parser in that it uses instruction types
to create parent-child instructions. The new parser always assumes that `drop`
is meant to drop just a single value because that's what it does in WebAssembly.

Since we want to continue to let `Drop` IR expressions consume tuples, and since
we will need a way to write tests for that IR pattern that work with the new
parser, introduce a new pseudoinstruction, `tuple.drop`, to represent drops of
tuples. This pseudoinstruction only exists in the text format and it parses to
normal `Drop` expressions. `tuple.drop` takes the arity of its operand as an
immediate, which will let the new parser parse it correctly in the future.