| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
We previously had a bug where we would begin and end an IRBuilder context for
imported functions even though they don't have bodies. For functions that return
results, ending this empty scope should have produced an error except that we
had another bug where we only produced that error for multivalue functions. We
did not previously have imported multivalue functions in wat-kitchen-sink.wast,
so both of these bugs went undetected. Fix both bugs and update the test to
include an imported multivalue function so that it would have failed without
this fix.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Add a `visitFunctionStart` function to IRBuilder and make it responsible for
setting the function's body when the context is closed. This will simplify
outlining, will be necessary to support branches to function scope properly, and
removes an extra block around function bodies in the new wat parser.
|
| |
|
|
|
|
|
|
|
|
|
| |
The new wat parser previously returned InstrT types when parsing individual
instructions and collected InstrsT types when parsing sequences of instructions.
However, instructions were always actually tracked in the internal state of the
parsing context, so these types never held any interesting or necessary data.
Simplify the parser by removing these types and leaning into the pattern that
the parser context will keep track of parsed instructions.
This allows for a much cleaner separation between the `instrs` and
`foldedinstrs` parser functions.
|
|
|
And put the new files in a new source directory, "parser". This is a rough split
and is not yet expected to dramatically improve compile times. The exact
organization of the new files is subject to change, but this splitting should be
enough to make further parser development more pleasant.
|
