summaryrefslogtreecommitdiff
path: root/test/lit/help/wasm-ctor-eval.test
Commit message (Collapse)AuthorAgeFilesLines
* Remove the --hybrid and --nominal command line options (#5669)Thomas Lively2023-04-141-7/+0
| | | | | After this change, the only type system usable from the tools will be the standard isorecursive type system. The nominal type system is still usable via the API, but it will be removed entirely in a follow-on PR.
* [wasm-ctor-eval] Add support for multivalue serialization and a quiet mode ↵Alon Zakai2023-02-231-0/+3
| | | | | | | | | | (#5510) Simply loop over the values and use tuple.make. This also adds a lit test for ctor-eval. I found that the problem blocking us before was the logging, which confuses the update script. As this test at least does not require that logging, this PR adds a --quiet flag that disables the logging, and then a lit test just works.
* Move closed world flag to tool options (#5428)Alon Zakai2023-01-131-0/+7
| | | | This allows tools like wasm-reduce to be told to operate in closed-world mode. That lets them validate in the more strict way of that mode.
* Remove equirecursive typing (#5240)Thomas Lively2022-11-231-4/+0
| | | | Equirecursive is no longer standards track and its implementation is extremely complex. Remove it.
* Temporarily restore the typed-function-references flags as no-ops (#5050)Thomas Lively2022-09-161-68/+74
| | | | | This allows a three-step upgrade process where binaryen is updated with this change, then users remove their use of these flags, then binaryen can remove the flags permanently.
* Remove typed-function-references feature (#5030)Thomas Lively2022-09-091-74/+68
| | | | | | | | | | | | | | | | In practice typed function references will not ship before GC and is not independently useful, so it's not necessary to have a separate feature for it. Roll the functionality previously enabled by --enable-typed-function-references into --enable-gc instead. This also avoids a problem with the ongoing implementation of the new GC bottom heap types. That change will make all ref.null instructions in Binaryen IR refer to one of the bottom heap types. But since those bottom types are introduced in GC, it's not valid to emit them in binaries unless unless GC is enabled. The fix if only reference types is enabled is to emit (ref.null func) instead of (ref.null nofunc), but that doesn't always work if typed function references are enabled because a function type more specific than func may be required. Getting rid of typed function references as a separate feature makes this a nonissue.
* Adding Multi-Memories Wasm Feature (#4968)Ashley Nelson2022-08-251-0/+4
| | | Adding multi-memories to the the list of wasm-features.
* [Strings] Add feature flag for Strings proposal (#4766)Alon Zakai2022-06-301-0/+4
|
* Add support for extended-const proposal (#4529)Sam Clegg2022-03-191-0/+4
| | | See https://github.com/WebAssembly/extended-const
* [Docs] Document wasm-ctor-eval (#4493)Alon Zakai2022-02-031-1/+1
|
* Add a `--hybrid` type system option (#4460)Thomas Lively2022-01-191-0/+4
| | | | | Eventually this will enable the isorecursive hybrid type system described in https://github.com/WebAssembly/gc/pull/243, but for now it just throws a fatal error if used.
* [ctor-eval] Add an option to keep some exports (#4441)Alon Zakai2022-01-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | By default wasm-ctor-eval removes exports that it manages to completely eval (if it just partially evals then the export remains, but points to a function with partially-evalled contents). However, in some cases we do want to keep the export around even so, for example during fuzzing (as the fuzzer wants to call the same exports before and after wasm-ctor-eval runs) and also if there is an ABI we need to preserve (like if we manage to eval all of main()), or if the function returns a value (which we don't support yet, but this is a PR to prepare for that). Specifically, there is now a new option: --kept-exports foo,bar That is a list of exports to keep around. Note that when we keep around an export after evalling the ctor we make the export point to a new function. That new function just contains a nop, so that nothing happens when it is called. But the original function is kept around as it may have other callers, who we do not want to modify.
* [ctor-eval] Add --ignore-external-input option (#4428)Alon Zakai2022-01-061-0/+3
| | | | | | | | | | | | This is meant to address one of the main limitations of wasm-ctor-eval in emscripten atm, that libc++ global ctors will read env vars, which means they call an import, which stops us from evalling, emscripten-core/emscripten#15403 (comment) To handle that, this adds an option to ignore external input. When set, we can assume that no env vars will be read, no reading from stdin, no arguments to main(), etc. Perhaps these could each be separate options, but I think keeping it simple for now might be good enough.
* Add categories to --help text (#4421)Alon Zakai2022-01-051-6/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The general shape of the --help output is now: ======================== wasm-foo Does the foo operation ======================== wasm-foo opts: -------------- --foo-bar .. Tool opts: ---------- .. The options are now in categories, with the more specific ones - most likely to be wanted by the user - first. I think this makes the list a lot less confusing. In particular, in wasm-opt all the opt passes are now in their own category. Also add a script to make it easy to update the help tests.
* Add a --structural flag (#4252)Thomas Lively2021-10-161-12/+1
| | | | | | | | | Just as the --nominal flag forces all types to be parsed as nominal, the --structural flag forces all types to be parsed as equirecursive. This is the current default behavior, but a future PR will change the default to parse types as either structural or nominal according to their syntax or encoding. This new flag will then be necessary to get the current behavior. Also take this opportunity to deduplicate more flags in the help tests.
* Lit tests for tool help messages (#3965)Thomas Lively2021-07-071-0/+29
Add list tests for the help messages of all tools, factoring out common options into shared tests. This is slightly brittle because the text wrapping depends on the length of the longest option, but that brittleness should be worth the benefit of being able to see the actual help text in the tests.