446: apply base path update to wasi::path_filestat_get r=MarkMcCaskey a=MarkMcCaskey
resolves#434 (again)
causes `path_filestat_get` to start at the base path calculated from the fd passed in. This technique was applied to `path_open` but didn't make it to `path_filestat_get`, this fixes that
Co-authored-by: Mark McCaskey <mark@wasmer.io>
445: Better README.md link target for "WASI" r=Hywan a=Uzume
Just updating the link target for "WASI" in the readme.
Co-authored-by: Uzume <uzume@users.osdn.me>
443: Return impl Compiler from default_compiler to fix compilation features r=bjfish a=bjfish
runtime compilation was failing (llvm/singlepass features) for the new compiler implementations for the `default_compiler` function due to changing types and state being added to the compilers.
This PR:
- adds runtime library tests for these features to catch the regression earlier
- refactors `default_compiler` to return `impl Compiler` and no longer a singleton to fix the compilation issue
Co-authored-by: Brandon Fish <brandon.j.fish@gmail.com>
Co-authored-by: Brandon Fish <bjfish@users.noreply.github.com>
440: fix(runtime-c-api) `wasmer_instance_call` types must matche `wasmer_export_func_*_arity` r=Hywan a=Hywan
The `wasmer_export_func_params_arity` and
`wasmer_export_func_returns_arity` functions store the arity in a
`uint32_t`. The `wasmer_instance_call` expects `c_int`. There is a
type mismatch here. It's not annoying in C or C++, but in some other
languages that have bindings to C/C++, it can imply useless casting.
This patch changes `wasmer_instance_call` to expect `uint32_t` for
`params_len` and `results_len` to match the
`wasmer_export_func_*_arity` functions.
Other patches do the same for `wasmer_export_func_params` and
`wasmer_export_func_returns`.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
The `returns_len` argument type of `wasmer_export_func_returns_params`
must be `uint32_t` to match the `wasmer_export_func_returns_arity` results,
so that casts are not required.
The `params_len` argument type of `wasmer_export_func_params_arity`
must be `uint32_t` to match the `wasmer_export_func_*_arity` results,
so that casts are not required.
The `wasmer_export_func_params_arity` and
`wasmer_export_func_returns_arity` functions store the arity in a
`uint32_t`. The `wasmer_instance_call` expects `c_int`. There is a
type mismatch here. It's not annoying in C or C++, but in some other
languages that have bindings to C/C++, it can imply useless casting.
This patch changes `wasmer_instance_call` to expect `uint32_t` for
`params_len` and `results_len` to match the
`wasmer_export_func_*_arity` functions.
