* Allow returning structs if copy
This commit does three things:
1. enables marshalling of structs as return args from interface funcs
but so far *only* for the case when the struct itself is copy
2. puts bits that use `std::convert::TryInto` in a local scope to avoid
multiple reimports
3. for added clarity, we now print for which `tref` type the marshalling
of results is unimplemented
The first case (1.) is required to make `fd_fdstat_get` WASI interface
func work which returns `Fdstat` struct (which is copy). The second
case (2.) caused me some grief somewhere along the lines when I was
playing with snapshot1. Putting the code that requires it inside a local
scope fixed all the issues
* Add proptests for returing struct if copyable
* Use write_ptr_to_guest to marshal value to guest
* Successfully return non-copy struct
This commit aligns `wiggle` a little bit closer with Rust proper in
the sense that now `GuestTypeCopy` implies `GuestTypeClone` which
in turn implies that any type implementing `GuestTypeCopy` will have
to provide `read_from_guest` and `write_to_guest` methods. As a result,
we can safely revert changes introduced in the previous commit.
This commit fixes stubs for struct members that are `GuestTypeCopy`
but are not `GuestTypeClone`. In this case, we cannot rely on methods
`T::read_from_guest` or `T::write_to_guest` since these are only
available if `T: GuestTypeClone`. In those cases, we can and should
dereference the location pointer to `T` and copy the result in/out
respectively.
If write doesn't write the full buffer, start the next write at the
point where the write left off.
Also, usize `ssize_t` for the return types of `read` and `write`.
This commit renames `wasi_config_set_std[in|out|err]` to
`wasi_config_set_std[in|out|err]_file` so we can reserve the former for
when the C API supports a stream abstraction.
This commit makes `WasiCtxBuilder` take `&mut Self` and return `&mut
Self` for its methods. This is needed to allow for the same
(unmoved) `WasiCtxBuilder` to be used when building a WASI context.
Also fixes up the C API to remove the unnecessary `Box::from_raw` and
`forget` calls which were previously needed for the moving version of
`WasiCtxBuilder`.
* Update rust embed example (#967)
Ensures that the example works with the current API.
Drops mention of HostRef as the example is complete without it.
* Cleanup
This commit implements an initial WASI C API that can be used to instantiate
and configure a WASI instance from C.
This also implements a `WasiBuilder` for the C# API enabling .NET hosts to bind
to Wasmtime's WASI implementation.
* Optimize generated code via the CLI by default
This commit updates the behavior of the CLI and adds a new flag. It
first enables the `--optimize` flag by default, ensuring that usage of
the `wasmtime` CLI will enable cranelift optimizations by default. Next
it also adds a `--opt-level` flag which is similar to Rust's
`-Copt-level` where it takes a string argument of how to optimize. This
is updates to support 0/1/2/s, where 1 is currently the same as 2 but
added for consistency with other compilers. The default setting is
`--opt-level=2`.
When the `-O` flag is not passed the `--opt-level` flag is used,
otherwise `-O` takes precedent in the sense that it implies
`--opt-level=2` which is the highest optimization level. The thinking is
that these flags will in general select the highest optimization level
specified as the final optimization level.
* Add inline docs
* fix a test
* Implement fmt::Display for enums
`wasi_common` relies on `strerror` to nicely format error messages.
`strerror` is autoimplemented in `wig`. I thought it might be useful
to provide a Rust-idiomatic alternative which boils down to autoimplementing
`fmt::Display` for all enums.
* Implement fmt::Display for flags
* Implement fmt::Display for ints
This commit is an attempt to fix the issue pointed out at
https://github.com/bytecodealliance/wasmtime/issues/312#issuecomment-576429580
where our publication to pypi is failing (and causes our binary release
process to also fail). By updating the dependency here we should pull in
the necessary support to support the `packages_dir` option.
The `wasmtime` release procees seems like it's been a bit ad-hoc up to
this point, so I figured it'd be good to try to document what we do
today and codify what should be done as well as a form of release
checklist.
I've noticed that we have a number of releases (like v0.11.0) but the
`Cargo.toml` files in the repository don't reflect the current version
of `wasmtime`. Additionally I've noticed that the [most recent release]
ended up having failed tests because `Cargo.toml` was modified but
`Cargo.lock` wasn't updated. I'm hoping that by having a checklist we
can avoid these sorts of accidental issues in the future!
[release]: https://github.com/bytecodealliance/wasmtime/runs/434690272
This commit does a bit of everything: refactors bits here and there,
fixes a bug discovered in another #701, and combines all structs that
we used in `yanix` and `wasi-common` crates to represent file types
on *nix into one struct, `yanix::file::FileType`.
Up until now, in `yanix`, we've had two separate structs used to
represent file types on the host: `yanix::dir::FileType` and
`yanix::file::SFlags` (well, not quite, but that was its main use).
They both were used in different context (the former when parsing
`dirent` struct, and the latter when parsing `stat` struct), they
were C-compatible (as far as their representation goes), and as it
turns out, they shared possible enumeration values. This commit
combines them both into an idiomatic Rust enum with the caveat that
it is now *not* C-compatible, however, I couldn't find a single use
where that would actually matter, and even if it does in the future,
we can simply add appropriate impl methods.
The combine `yanix::file::FileType` struct can be constructed in two
ways: 1) either from `stat.st_mode` value (and while we're here,
now it's done correctly according to POSIX which fixes the bug mentioned
in VFS impl PR #701), or 2) from `dirent.d_type` value. Also, since we now
have one struct for representing both contexts, this cleans up nicely
a lot of duplicated code in `host` module.
To fix this case that may take forever to compile:
function %a(){
ebb477777777:
}
We decide to define a maximum threshold for the number of blocks in functions.
Based on a large WASM program (https://github.com/mozilla/perf-automation/blob/master/benchmarks/wasm-misc/AngryBots.wasm),
its IR functions does not exceed 1414 blocks. A number 100 times greater (100,000 blocks) seems (currently) enough to define our maximum threshold.
To make this quick benchmark the cranelift-wasm/src/func_translator.rs file has been modified like this:
static mut MAX: usize = 0;
pub fn translate_from_reader<FE: FuncEnvironment + ?Sized>(...) {
[...]
builder.finalize();
// the compiler is single threaded
unsafe {
if func.dfg.num_ebbs() > MAX {
MAX = func.dfg.num_ebbs();
println!("MAX {}", MAX);
}
}
Ok(())
}
This allows getN to return a detailed explanation of any type signature
mismatch, and makes it easy to just use `?` on the result of getN rather
than constructing a (necessarily vaguer) error message in the caller.
* Cargo.lock: Update, to no longer use multiple versions of autocfg
* Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0
This also eliminates duplicate versions of gimli and arrayvec, and
eliminates the nodrop dependency entirely.
* Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0
This also eliminates two duplicate versions of goblin, and duplicate
versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid.
* Update wasmtime-profiling to current scroll 0.10.1
This eliminates duplicate versions of scroll.
* Update wasmtime-profiling to current target-lexicon 0.10.0
This eliminates duplicate versions of target-lexicon.
* Update wasmtime-interface-types to current walrus and wasm-webidl-bindings
This also eliminates the oldest of the three duplicate versions of
wasmparser.
* Update wasmtime-wast to current wast 8.0.0
This eliminates one of the duplicate versions of wast.
* Func: Number type arguments rather than using successive letters
This simplifies future extension, and avoids potential conflicts with
other type argument names.
* Extend Func::getN up to get10, allowing up to 10-argument functions
* atoms in one test unit
* factor out pointers test
* factor structs into separate test unit
* factor out arrays, flags
* finally, separate into strings and ints
* move trap site definitions into cranelift-module
`cranelift-faerie` and `cranelift-object` already have identical
definitions of structures to represent trap sites. We might as well
merge them ahead of work to define functions via a raw slice of bytes
with associated traps, which will need some kind of common structure for
representing traps anyway.
* cranelift-module: add `define_function_bytes` interface
This interface is useful when the client needs to precisely specify the
ordering of bytes in a particular function.
* add comment about saving files for `perf`
* Draft out IntDatatype in wiggle-generate
This commit drafts out basic layout for `IntDatatype` structure in
`wiggle`. As it currently stands, an `Int` type is represented as
a one-element tuple struct much like `FlagDatatype`, however, with
this difference that we do not perform any checks on the input
underlying representation since any value for the prescribed type
is legal.
* Finish drafting IntDatatype support in wiggle
This commit adds necessary marshal stubs to properly pass `IntDatatype`
in and out of interface functions. It also adds a basic proptest.
