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.
432: feat(runtime-c-api) Check buffer size before creating the slice, and fix `wasmer_last_error_message` returned value r=Hywan a=Hywan
It's safer to check the buffer size is large enough to hold the error
message before creating the slice from raw parts.
Also, this patch remove the need for `last_error`, simplifying the
code a little bit. The `length` variable is casted to `usize` once.
This patch also updates the returned value of `wasmer_last_error_message` by adding 1, so that it mimics the `wasmer_last_error_length` function that counts the trailing null byte.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
435: Fix f32/f64 conversion, add tests, and rename conversion method r=syrusakbary a=bjfish
Fixes#415
I believe removing this conversion here caused the regression: https://github.com/wasmerio/wasmer/pull/379/files#diff-5e7e23717d05d1d18be5b2e3b75f454dL158
I've added conversion tests and also renamed `NativeWasmType::{to_bits, from_bits}` to `to_binary/from_binary` because it seemed akward to overload the existing `f32::to_bits` method.
Co-authored-by: Brandon Fish <brandon.j.fish@gmail.com>
429: implement some FS operations for rsign2 r=MarkMcCaskey a=MarkMcCaskey
Get https://github.com/jedisct1/rsign2 working with WASI on Wasmer (for end-to-end tests of wapm)
Current implementation is very hacky, but works! It should have a couple passes of improvement before shipping
Co-authored-by: Mark McCaskey <mark@wasmer.io>
It's safer to check the buffer size is large enough to hold the error
message before creating the slice from raw parts.
Also, this patch remove the need for `last_error`, simplifying the
code a little bit. The `length` variable is casted to `usize` once.
413: Use the new code generator API for LLVM backend. r=syrusakbary a=losfair
Co-authored-by: Brandon Fish <brandon.j.fish@gmail.com>
Co-authored-by: losfair <zhy20000919@hotmail.com>
Co-authored-by: Brandon Fish <bjfish@users.noreply.github.com>
