summaryrefslogtreecommitdiff
path: root/test/passes/Oz_fuzz-exec_all-features.wast
Commit message (Collapse)AuthorAgeFilesLines
* Properly stringify names in tests (#6279)Thomas Lively2024-02-061-2/+2
| | | | | | | | | | | | | Update identifiers used in tests to use a format supported by the new text parser, i.e. either the standard format with its limited set of allowed characters or the non-standard `$"..."` format. Notably, any name containing square or curly braces now uses the string format. Input automatically updated with this script: https://gist.github.com/tlively/4e22311736661849e641d02e521a0748 The printer is updated to properly escape names in more places as well. The logic for escaping names is moved to a common location so that the type printing logic in wasm-type.cpp can use it as well.
* Fix incorrect wat in tests (#6207)Thomas Lively2024-01-081-2/+2
| | | | | | | | | The new wat parser is much more strict than the legacy wat parser; the latter accepts all sorts of things that the spec does not allow. To ease an eventual transition to using the new wat parser by default, update the tests to use the standard text format in many places where they previously did not. We do not yet have a way to prevent new errors from being introduced into the test suite, but at least there will now be many fewer errors when it comes time to make the switch.
* Drop support for type annotations on array.len (#6197)Thomas Lively2024-01-031-2/+2
| | | | | | These type annotations were removed during the development of the GC proposal, but we maintained support for parsing them to ease the transition. Now that GC is shipped, remove support for the non-standard annotation and update our tests accordingly.
* Drop support for non-standard quoted function names (#6188)Thomas Lively2023-12-201-20/+20
| | | | | | | | | | | | | | | | | | We previously supported a non-standard `(func "name" ...` syntax for declaring functions exported with the quoted name. Since that is not part of the standard text format, drop support for it, replacing it with the standard `(func $name (export "name") ...` syntax instead. Also replace our other usage of the quoted form in our text output, which was where we quoted names containing characters that are not allowed to appear in standard names. To handle that case, adjust our output from `"$name"` to `$"name"`, which is the standards-track way of supporting such names. Also fix how we detect non-standard name characters to match the spec. Update the lit test output generation script to account for these changes, including by making the `$` prefix on names mandatory. This causes the script to stop interpreting declarative element segments with the `(elem declare ...` syntax as being named "declare", so prevent our generated output from regressing by counting "declare" as a name in the script.
* Remove legacy type defintion text syntax (#5948)Thomas Lively2023-09-181-1/+1
| | | | | | | Remove support for the "struct_subtype", "array_subtype", "func_subtype", and "extends" notations we used at various times to declare WasmGC types, leaving only support for the standard text fromat for declaring types. Update all the tests using the old formats and delete tests that existed solely to test the old formats.
* Replace i31.new with ref.i31 everywhere (#5931)Thomas Lively2023-09-131-1/+1
| | | | | Replace i31.new with ref.i31 in the printer, tests, and source code. Continue parsing i31.new for the time being to allow a graceful transition. Also update the JS API to reflect the new instruction name.
* Make final types the default (#5918)Thomas Lively2023-09-091-1/+1
| | | | | | | | | | | | | Match the spec and parse the shorthand binary and text formats as final and emit final types without supertypes using the shorthands as well. This is a potentially-breaking change, since the text and binary shorthands can no longer be used to define types that have subtypes. Also make TypeBuilder entries final by default to better match the spec and update the internal APIs to use the "open" terminology rather than "final" terminology. Future changes will update the text format to use the standard "sub open" rather than the current "sub final" keywords. The exception is the new wat parser, which supporst "sub open" as of this change, since it didn't support final types at all previously.
* Use the standard syntax for ref.cast, ref.test and array.new_fixed (#5894)Jérôme Vouillon2023-08-231-12/+12
| | | | | | | | | * Update text output for `ref.cast` and `ref.test` * Update text output for `array.new_fixed` * Update tests with new syntax for `ref.cast` and `ref.test` * Update tests with new `array.new_fixed` syntax
* Remove legacy WasmGC instructions (#5861)Thomas Lively2023-08-091-1/+1
| | | | | Remove old, experimental instructions and type encodings that will not be shipped as part of WasmGC. Updating the encodings and text format to match the final spec is left as future work.
* Update br_on_cast binary and text format (#5762)Thomas Lively2023-06-121-7/+7
| | | | | | | | | | | | The final versions of the br_on_cast and br_on_cast_fail instructions have two reference type annotations: one for the input type and one for the cast target type. In the binary format, this is represented as a flags byte followed by two encoded heap types. Upgrade all of the tests at once to use the new versions of the instructions and drop support for the old instructions from the text parser. Keep support in the binary parser to avoid breaking users, though. Drop some binary tests of deprecated instruction encodings that would be more effort to update than they're worth. Re-land with fixes of #5734
* Revert "Update br_on_cast binary and text format (#5734)" (#5740)Alon Zakai2023-05-231-7/+7
| | | | | | | This reverts commit b7b1d0df29df14634d2c680d1d2c351b624b4fbb. See comment at the end of #5734: It turns out that dropping the old opcodes causes problems for current users, so let's revert this for now, and later we can figure out how best to do the update.
* Update br_on_cast binary and text format (#5734)Thomas Lively2023-05-191-7/+7
| | | | | | | | | | The final versions of the br_on_cast and br_on_cast_fail instructions have two reference type annotations: one for the input type and one for the cast target type. In the binary format, this is represented as a flags byte followed by two encoded heap types. Since these instructions have been in flux for a while, do not attempt to maintain backward compatibility with older versions of the instructions. Instead, upgrade all of the tests at once to use the new versions of the instructions. Drop some binary tests of deprecated instruction encodings that would be more effort to update than they're worth.
* Parse and print `array.new_fixed` (#5527)Thomas Lively2023-02-281-4/+4
| | | | | | | | | This is a (more) standard name for `array.init_static`. (The full upstream name in the spec repo is `array.new_canon_fixed`, but I'm still hoping we can drop `canon` from all the instruction names and it doesn't appear elsewhere in Binaryen). Update all the existing tests to use the new name and add a test specifically to ensure the old name continues parsing.
* Represent ref.as_{func,data,i31} with RefCast (#5413)Thomas Lively2023-01-101-8/+0
| | | | | | | | | | | | | These operations are deprecated and directly representable as casts, so remove their opcodes in the internal IR and parse them as casts instead. For now, add logic to the printing and binary writing of RefCast to continue emitting the legacy instructions to minimize test changes. The few test changes necessary are because it is no longer valid to perform a ref.as_func on values outside the func type hierarchy now that ref.as_func is subject to the ref.cast validation rules. RefAsExternInternalize, RefAsExternExternalize, and RefAsNonNull are left unmodified. A future PR may remove RefAsNonNull as well, since it is also expressible with casts.
* Support br_on_cast null (#5397)Thomas Lively2023-01-051-1/+1
| | | | | | | | | As well as br_on_cast_fail null. Unlike the existing br_on_cast* instructions, these new instructions treat the cast as succeeding when the input is a null. Update the internal representation of the cast type in `BrOn` expressions to be a `Type` rather than a `HeapType` so it will include nullability information. Also update and improve `RemoveUnusedBrs` to handle the new instructions correctly and optimize in more cases.
* Use non-nullable ref.cast for non-nullable input (#5335)Thomas Lively2022-12-091-2/+2
| | | | | | | | | | | | We switched from emitting the legacy `ref.cast_static` instruction to emitting `ref.cast null` in #5331, but that wasn't quite correct. The legacy instruction had polymorphic typing so that its output type was nullable if and only if its input type was nullable. In contrast, `ref.cast null` always has a a nullable output type. Fix our output by instead emitting non-nullable `ref.cast` if the output should be non-nullable. Parse `ref.cast` in binary and text forms as well. Since the IR can only represent the legacy polymorphic semantics, disallow unsupported casts from nullable to non-nullable references or vice versa for now.
* Allow casting to basic heap types (#5332)Thomas Lively2022-12-081-8/+0
| | | | | | | The standard casting instructions now allow casting to basic heap types, not just user-defined types, but they also require that the intended type and argument type have a common supertype. Update the validator to use the standard rules, update the binary parser and printer to allow basic types, and update the tests to remove or modify newly invalid test cases.
* Add standard versions of WasmGC casts (#5331)Thomas Lively2022-12-071-19/+19
| | | | | | | We previously supported only the non-standard cast instructions introduced when we were experimenting with nominal types. Parse the names and opcodes of their standard counterparts and switch to emitting the standard names and opcodes. Port all of the tests to use the standard instructions, but add additional tests showing that the non-standard versions are still parsed correctly.
* Update tests ahead of transition from `data` to `struct` (#5320)Thomas Lively2022-12-071-78/+1
| | | | | | | | | | The upstream WasmGC spec has removed `data` and introduced `struct`. To make the migration easier, we have been supporting `struct` as an `alias` for `data` and `structref` as an alias for `dataref`. Update the tests to prefer the `struct` aliases over `data` for test input to make the future migration easier. Also update some tests that had stale comments about ref.null types being updated and remove some tests for instructions like br_on_data and ref.as_data that do not make sense without a `data` type.
* Revert "Revert "Make `call_ref` type annotations mandatory (#5246)" (#5265)" ↵Thomas Lively2022-11-161-2/+2
| | | | | (#5266) This reverts commit 570007dbecf86db5ddba8d303896d841fc2b2d27.
* Revert "Make `call_ref` type annotations mandatory (#5246)" (#5265)Thomas Lively2022-11-161-2/+2
| | | | | This reverts commit b2054b72b7daa89b7ad161c0693befad06a20c90. It looks like the necessary V8 change has not rolled out everywhere yet.
* Make `call_ref` type annotations mandatory (#5246)Thomas Lively2022-11-151-2/+2
| | | | They were optional for a while to allow users to gracefully transition to using them, but now make them mandatory to match the upstream WasmGC spec.
* Separate `func` into a separate type hierarchy (#4955)Thomas Lively2022-08-221-4/+6
| | | | | Just like `extern` is no longer a subtype of `any` in the new GC type system, `func` is no longer a subtype of `any`, either. Make that change in our type system implementation and update tests and fuzzers accordingly.
* Remove RTTs (#4848)Thomas Lively2022-08-051-181/+29
| | | | | | | RTTs were removed from the GC spec and if they are added back in in the future, they will be heap types rather than value types as in our implementation. Updating our implementation to have RTTs be heap types would have been more work than deleting them for questionable benefit since we don't know how long it will be before they are specced again.
* Fix RTTs for RTT-less instructions (#4294)Thomas Lively2021-11-031-1/+3
| | | | | | | | | | | | Allocation and cast instructions without explicit RTTs should use the canonical RTTs for the given types. Furthermore, the RTTs for nominal types should reflect the static type hierarchy. Previously, however, we implemented allocations and casts without RTTs using an alternative system that only used static types rather than RTT values. This alternative system would work fine in a world without first-class RTTs, but it did not properly allow mixing instructions that use RTTs and instructions that do not use RTTs as intended by the M4 GC spec. This PR fixes the issue by using canonical RTTs where appropriate and cleans up the relevant casting code using std::variant.
* [Wasm GC] Implement static (rtt-free) StructNew, ArrayNew, ArrayInit (#4172)Alon Zakai2021-09-231-13/+6
| | | | | | | | | See #4149 This modifies the test added in #4163 which used static casts on dynamically-created structs and arrays. That was technically not valid (as we won't want users to "mix" the two forms). This makes that test 100% static, which both fixes the test and gives test coverage to the new instructions added here.
* [Wasm GC] Add static variants of ref.test, ref.cast, and br_on_cast* (#4163)Alon Zakai2021-09-201-0/+94
| | | | | | | | | | | | These variants take a HeapType that is the type we intend to cast to, and do not take an RTT. These are intended to be more statically optimizable. For now though this PR just implements the minimum to get them parsing and to get through the optimizer without crashing. Spec: https://docs.google.com/document/d/1afthjsL_B9UaMqCA5ekgVmOm75BVFu6duHNsN9-gnXw/edit# See #4149
* Fix interpreting of ref.as_func|data (#4164)Alon Zakai2021-09-201-0/+34
|
* [Wasm GC] Fix lack of packing in array.init (#4153)Alon Zakai2021-09-141-0/+13
|
* [Wasm GC] ArrayInit support (#4138)Alon Zakai2021-09-101-0/+22
| | | | | | | array.init is like array.new_with_rtt except that it takes as arguments the values to initialize the array with (as opposed to a size and an optional initial value). Spec: https://docs.google.com/document/d/1afthjsL_B9UaMqCA5ekgVmOm75BVFu6duHNsN9-gnXw/edit#
* [Wasm GC] rtt.fresh_sub (#3936)Alon Zakai2021-06-171-0/+44
| | | | | | | | | | This is the same as rtt.sub, but creates a "new" rtt each time. See https://docs.google.com/document/d/1DklC3qVuOdLHSXB5UXghM_syCh-4cMinQ50ICiXnK3Q/edit# The old Literal implementation of rtts becomes a little more complex here, as it was designed for the original spec where only structure matters. It may be worth a complete redesign there, but for now as the spec is in flux I think the approach here is good enough.
* [Wasm GC] Add negated BrOn* operations (#3913)Alon Zakai2021-06-021-0/+115
| | | | | | They are basically the flip versions. The only interesting part in the impl is that their returned typed and sent types are different. Spec: https://docs.google.com/document/d/1DklC3qVuOdLHSXB5UXghM_syCh-4cMinQ50ICiXnK3Q/edit
* [Wasm GC] Add experimental array.copy (#3911)Alon Zakai2021-05-271-0/+48
| | | | | | | | Spec for it is here: https://docs.google.com/document/d/1DklC3qVuOdLHSXB5UXghM_syCh-4cMinQ50ICiXnK3Q/edit# Also reorder some things in wasm.h that were not in the canonical order (that has no effect, but it is confusing to read).
* [Wasm GC] Fix casting code in interpreter (#3873)Alon Zakai2021-05-101-0/+12
| | | | | | | | | | The logic there would construct the cast value separately for functions and data (as we must), and then in an attempt to share code, would then check if the cast succeed or not (and if not, do nothing with the cast value). But this was wrong, as in some weird casts (like a struct to a function) we cannot construct a valid cast value, and we error there. Instead, check if the cast works first, once we know enough to do so, and only then construct the cast value if so.
* [Wasm GC] Fix Array initialization of a packed value (#3868)Alon Zakai2021-05-071-0/+15
| | | | | | We truncated and extended packed values in get and set, but not during initialization. Found by the fuzzer.
* [Wasm GC] Fix precompute on GC data (#3810)Alon Zakai2021-04-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes precomputation on GC after #3803 was too optimistic. The issue is subtle. Precompute will repeatedly evaluate expressions and propagate their values, flowing them around, and it ignores side effects when doing so. For example: (block ..side effect.. (i32.const 1) ) When we evaluate that we see there are side effects, but regardless of them we know the value flowing out is 1. So we can propagate that value, if it is assigned to a local and read elsewhere. This is not valid for GC because struct.new and array.new have a "side effect" that is noticeable in the result. Each time we call struct.new we get a new struct with a new address, which ref.eq can distinguish. So when this pass evaluates the same thing multiple times it will get a different result. Also, we can't precompute a struct.get even if we know the struct, not unless we know the reference has not escaped (where a call could modify it). To avoid all that, do not precompute references, aside from the trivially safe ones like nulls and function references (simple constants that are the same each time we evaluate the expression emitting them). precomputeExpression() had a minor bug which this fixes. It checked the type of the expression to see if we can create a constant for it, but really it should check the value - since (separate from this PR) we have no way to emit a "constant" for a struct etc. Also that only matters if replaceExpression is true, that is, if we are replacing with a constant; if we just want the value internally, we have no limit on that. Also add Literal support for comparing GC refs, which is used by ref.eq. Without that tiny fix the tests here crash. This adds a bunch of tests, many for corner cases that we don't handle (since the PR makes us not propagate GC references). But they should be helpful if/when we do, to avoid the mistakes in #3803
* Fuzzer: Distinguish traps from host limitations (#3801)Alon Zakai2021-04-121-0/+15
| | | | | | | | | Host limitations are arbitrary and can be modified by optimizations, so ignore them. For example, if the optimizer removes allocations then a host limit on an allocation error may vanish. Or, an optimization that removes recursion and replaces it with a loop may avoid a host limit on call depth (that is not done currently, but might some day). This removes a class of annoying false positives in the fuzzer.
* [GC] Do not crash on unreasonable GC array allocations in interpreter; trap ↵Alon Zakai2021-04-071-1/+9
| | | | | | | | | | (#3559) The spec does not mention traps here, but this is like a JS VM trapping on OOM - a runtime limitation is reached. As these are not specced traps, I did not add them to effects.h. Note how as a result the optimizer happily optimizes into a nop an unused allocation of an array of size unsigned(-1), which is the behavior we want.
* [Wasm GC] Add support for non-nullable types, all except for locals (#3710)Alon Zakai2021-03-231-1/+6
| | | | | | | | | | | | | | | | | | | | | | After this PR we still do not support non-nullable locals. But we no longer turn all types into nullable upon load. In particular, we support non-nullable types on function parameters and struct fields, etc. This should be enough to experiment with optimizations in both binaryen and in VMs regarding non- nullability (since we expect that optimizing VMs can do well inside functions anyhow; it's non-nullability across calls and from data that the VM can't be expected to think about). Let is handled as before, by lowering it into gets and sets. In addition, we turn non-nullable locals into nullable ones, and add a ref.as_non_null on all their gets (to keep the type identical there). This is used not just for loading code with a let but also is needed after inlining. Most of the code changes here are removing FIXMEs for allowing non-nullable types. But there is also code to handle the issues mentioned above. Most of the test updates are removing extra nulls that we added before when we turned all types nullable. A few tests had actual issues, though, and also some new tests are added to cover the code changes here.
* [Wasm GC] Validate static subtyping in rtt.sub (#3696)Alon Zakai2021-03-161-1/+1
| | | | Also add more spec tests, including one that verifies we validate rtt.sub and on a global location as fixed by #3694
* [Wasm GC] ref.cast and ref.test should have zero immediates (#3641)Alon Zakai2021-03-021-11/+11
| | | This updates them to be correct in the current spec and prototype v3.
* [Wasm GC] Fix the order of operands in array.new and struct.new (#3617)Alon Zakai2021-02-251-4/+4
| | | Also add a missing source file for a GC test, let.wasm.
* [GC] Support casts of function types (#3554)Alon Zakai2021-02-091-0/+30
| | | | | | | | | | | | | | | I had completely missed that the spec allows ref.cast etc. of function types, and not just data. Function types do not have an RTT, unlike GC data, but we can still cast them. A function reference has the canonical RTT of the signature for that type, so it's like a simplified case of the GC world, without a hierarchy of RTTs. As it turns out, our validation did not rule out rtt.canon of a function type, nor ref.cast of one, so we unintentionally already had all the support for this aside from the actual casting, which this PR adds. The addition is mostly trivial, except that we now need a Module in the base ExpressionRunner class, so that we can go from a function name to the actual function. This PR refactors things to allow that.
* [GC] dataref typing fixes (#3536)Alon Zakai2021-02-031-0/+12
| | | | | | | dataref was not noted as isRef, and we also did not handle the LUB for it, which caused validation errors. After these two fixes, it is possible to add a testcase that goes through the optimizer. View without whitespace as the LUB change has a lot of that.
* [GC] Update br_on_cast: the text format also no longer has a heap type (#3523)Alon Zakai2021-01-271-3/+3
| | | | | | | As a result, we cannot handle a br_on_cast with an unreachable RTT. The binary format solves the problem by ignoring unreachable code, and this makes the text format do the same. A nice benefit of this is that we can remove the castType extra field.
* [GC] RTT types are not defaultable (#3489)Alon Zakai2021-01-131-17/+11
| | | See WebAssembly/gc#175
* [GC] Fix casts of non-GC data (#3483)Alon Zakai2021-01-121-0/+11
| | | | | The code previously assumed it could always call getGCData, but that assumes the input is an array or a struct. It could also be an anyref etc. that contains something other than GC data.
* [GC] Validate that struct.set is to a mutable field. (#3473)Alon Zakai2021-01-081-1/+1
| | | | This required a few test fixes, to ensure we don't have invalid wasts with writes to immutable fields.
* [GC] Add br_on_cast (#3451)Alon Zakai2020-12-171-0/+38
| | | | | | | | | | | | | | | | The tricky part here, as pointed out by aheejin in my previous attempt, is that we need to know the type of the value we send if the branch is taken. We can normally calculate that from the rtt parameter's type - we are casting to that RTT, so we know what type that is - but if the rtt is unreachable, that's a problem. To fix that, store the cast type on BrOnCast instructions. This includes a test with a br_on_cast that succeeds and sends the cast value, one that fails and passes through the uncast value, and also of one with an unreachable RTT. This includes a fix for Precompute, as noticed by that new test. If a break is taken, with a ref as a value, we can't precompute it - for the same reasons we can't precompute a ref in general, that it is a pointer to possibly shared data.
* [GC] Fully implement RTT semantics (#3441)Alon Zakai2020-12-151-0/+74
| | | | | | | | | | | | | | This adds info to RTT literals so that they can represent the chain of rtt.canon/sub commands that generated them, and it adds an internal RTT for each GC allocation (array or struct). The approach taken is to simply store the full chain of rtt.sub types that led to each literal. This is not efficient, but it is simple and seems sufficient for the semantics described in the GC MVP doc - specifically, only the types matter, in that repeated executions of rtt.canon/sub on the same inputs yield equal outputs. This PR fixes a bunch of minor issues regarding that, enough to allow testing of the optimization and execution of ref.test/cast.