* Temporarily remove support for interface types
This commit temporarily removes support for interface types from the
`wasmtime` CLI and removes the `wasmtime-interface-types` crate. An
error is now printed for any input wasm modules that have wasm interface
types sections to indicate that support has been removed and references
to two issues are printed as well:
* #677 - tracking work for re-adding interface types support
* #1271 - rationale for removal and links to other discussions
Closes#1271
* Update the python extension
Instead expose a number of boolean accessors which doesn't require users
to construct a foreign `Features` type and allows us to decouple the API
of the `wasmtime` crate from the underlying implementation detail.
* Rename the `wasmtime_api` library to match the containing `wasmtime` crate
Commit d9ca508f80 renamed the
`wasmtime-api` crate to `wasmtime`, but left the name of the library it
contains as `wasmtime_api`.
It's fairly unusual for a crate to contain a library with a different
name, and it results in rather confusing error messages for a user; if
you list `wasmtime = "0.7"` in `Cargo.toml`, you can't `use
wasmtime::*`, you have to `use wasmtime_api::*;`.
Rename the `wasmtime_api` library to `wasmtime`.
* Stop renaming wasmtime to api on imports
Various users renamed the crate formerly known as wasmtime_api to api,
and then used api:: prefixes everywhere; change those all to wasmtime::
and drop the renaming.
This commit does two things: 1) it fixes `wasmtime_rust::wasmtime` proc macro by
adding the missing import to the `__rt` module, and fixing the scoping inside
the macro itself; and 2) it augments the `wasmtime_rust::wasmtime` proc macro with
custom error messages in case the implementor forgets the `self` argument in the
trait methods.
This commit is an attempt to reduce the number of crates necessary to
link to when using `wasmtime::Config` in "default mode" or with only one
or two tweaks. The change moves to a builder-style pattern for `Config`
to only require importing crates as necessary if you configure a
particular setting. This then also propagates that change to `Context`
as well by taking a `Config` instead of requiring that all arguments are
passed alone.