b01effc8a9
While compilers should be conservative when targeting WebAssembly Core features, runtimes should be lenient as otherwise people need to constantly turn on all features. Currently, most examples have to turn on 2.0 features because compilers such as AssemblyScript and TinyGo use them by default. This matches the policy with the reality, and should make first time use easier. This top-levels an internal type as `api.CoreFeatures` and defaults to 2.0 as opposed to 1.0, our previous default. This is less cluttered than the excess of `WithXXX` methods we had prior to implementing all planned WebAssembly Core Specification 1.0 features. Finally, this backfills rationale as flat config types were a distinct decision even if feature set selection muddied the topic. Signed-off-by: Adrian Cole <adrian@tetrate.io>
This directory contains tests which use multiple packages. For example:
benchcontains benchmark tests.enginecontains variety of end-to-end tests, mainly to ensure the consistency in the behavior between engines.fuzzcasescontains variety of test cases found by wazero-fuzz.post1_0contains end-to-end tests for features finished after WebAssembly 1.0 (20191205).spectestcontains end-to-end tests with the WebAssembly specification tests.vstests and benchmarks VS other WebAssembly runtimes.
Note: This doesn't contain WASI tests, as there's not yet an official testsuite. Meanwhile, WASI functions are unit tested including via Text Format imports here