Add wasi:http support to the C API (#12950)

Fill out type information for components in C API (#11937)

* Fill out type information for components in C API

I've concluded that I'll want this for wasmtime-py so this fills out
type reflection

Fill out type information for components in C API (#11937)

* Fill out type information for components in C API

I've concluded that I'll want this for wasmtime-py so this fills out
type reflection for various items in the C API. This then additionally
extends the C++ API as well.

prtest:full

* Update crates/c-api/include/wasmtime/component/types/func.h

Co-authored-by: Joel Dice <[email protected]>

---------

Co-authored-by: Joel Dice <[email protected]>

show more ...

capi: Add `define_unknown_imports_as_traps` (#11962)

Specifically add this to the component-side of the API to mirror the
functionality for core wasm.

Supply type information in `func_new` for components (#11944)

Originally the `Linker::func_new` type for components was modeled after
core wasm where a type was provided when the type was defined. T

Supply type information in `func_new` for components (#11944)

Originally the `Linker::func_new` type for components was modeled after
core wasm where a type was provided when the type was defined. This was
difficult, however, because there's no way to construct types right now
and instead a component had to be created and compiled to acquire type
information from it. Later various refactorings meant that it was
possible to drop the type information entirely from `func_new` meaning
that it was "typeless" in a sense, and the functionality relied on the
tagged nature of `Val` which always knows its type.

This has proven a bit difficult to integrate into Python in some work
I've been doing. Namely in Python component values are (at least IMO)
best represented as native Python values where possible. Native Python
doesn't distinguish, however, between integer bit widths (or
signededness). This means that converting a Python value to a component
value requires type information to guide the conversion process.
Currently when defining a function in a linker there's no way to get at
this type information meaning that the types would need to be supplied
in Python, bringing up the same shortcomings of not being able to create
types.

In lieu of filling out type constructors, which is itself quite
nontrivial, I've opted to do the next-most-easiest thing which is to
supply the type to the callee when an import is invoked. This means that
the callee has all the type information necessary. While this is
somewhat costly in that it clones a few arcs it's expected to be a drop
in the bucket compared to the inefficiencies of `Val` so it's at least
in the same spirit of the cost of the API right now.

My intention is to use this to update the C API for components and
eventually end up with type information when Python is invoked in
wasmtime-py. Also while I'm using wasmtime-py as a motivating case here
that's sort of just one example of a host embedding which doesn't have
the full fidelity of Rust's type system and might benefit from this.

show more ...

Support resources in the C API of Wasmtime (#11920)

This commit builds on #11885 to build out support for resources in
components in the C API of Wasmtime. Support is effectively the same as
in Rust

Support resources in the C API of Wasmtime (#11920)

This commit builds on #11885 to build out support for resources in
components in the C API of Wasmtime. Support is effectively the same as
in Rust except more things are behind pointers and `ResourceDynamic` is
used under the hood instead of `Resource<T>` due to the lack of
monomorphization. Tests have been updated to go through some various
situations of ensuring that guest and host resources are representable
and can be manipulated.

show more ...

Fill out more of the C++ API for components (#11889)

* capi: Add a C++ API for `component::Linker`

Just a bare-bones API for now with functionality that's possible to fill
out. Notably instantiatio

Fill out more of the C++ API for components (#11889)

* capi: Add a C++ API for `component::Linker`

Just a bare-bones API for now with functionality that's possible to fill
out. Notably instantiation and defining functions is not yet possible in
C++. Some more feature-parity is also added with the core linkers as
well.

* capi: Add bindings for component instances

* capi: Delete wasip2.h header file

Upon reflection I realize that this is not actually necessary and is
otherwise a duplicate of the functionality in `wasi.h`. All of the
functionality in `wasi.h` is already supported to power WASIp2-defined
APIs in a linker, which is enabled by the `WasiView` trait redirecting
to the `WasiView for WasiP1Ctx` implementation. This is similar to how
the `wasmtime` CLI works where a P1 context is always created and then
it's conditionally used for either core wasm or components.

Effectively this is a deletion of duplicate functionality in the C API
but no underlying functionality is lost. Translating information to
preexisting WASI calls will work the same as using the wasip2 APIs before.

* capi: Start bindings for component functions

* capi: Bind component values in the C++ API

* capi: Finish bindings for component functions/linkers

All the pieces are now in place to use the C++ API in testing.

* Fix compilation of CLI

* Fix compile on MSVC

* Try again to fix msvc compat

* Fix `get_f32` and `get_f64` return values

* Fix signed return values

* Remove no-longer-needed `capi_transfer` function

* Try to fix msvc again

* Remove std::optional constructor of `Val`

* Fix another namespace clash on msvc

* One day I surely may understand a fraction of either C++ or MSVC, but
today is not that day.

* Document internal macro

* Add other internal docs

show more ...

c-api: component-model: Resource table, WASI (#11055)

* c-api: component-model: Resource table, WASI

* WASIP2 context builder

* Add include

* Rename function

* Add a simple test

* Add comments

c-api: component-model: Resource table, WASI (#11055)

* c-api: component-model: Resource table, WASI

* WASIP2 context builder

* Add include

* Rename function

* Add a simple test

* Add comments prtest:full

show more ...

Update nightly used in CI (#10957)

A new lint was added to rustc so this updates the nightly used in CI and
then additionally fixes the lints that are firing.

c-api: component-model: Values and function calling (#10697)

* c-api: component-model: Primitive values

* c-api: component-model: Function calling

* A test

* Take args as mut to avoid copying

*

c-api: component-model: Values and function calling (#10697)

* c-api: component-model: Primitive values

* c-api: component-model: Function calling

* A test

* Take args as mut to avoid copying

* String and char

* Rethink value ownership semantics, add list values

* Record values

* Make take Rust values as refs in `::from()` functions

Later we can provide implementations that take it as a value to avoid
copying

* Define host functions

* `wasmtime_component_valrecord_new()`

* Use `u32` instead of `char` as its not ffi safe

* Test records and strings in c-api -> vm -> host func -> vm -> c-api

* `wasmtime_component_vallist_new()`

* Test lists

* Fix formatting

* Use existing `declare_vecs` construct

* Add rest of helper functions

* Add documentation

* Fix multiline comments

* Third time's the charm

* Fourth time's the charm prtest:full

* Doxygen file headers

* Fix other missing documentation

* Small fix to docs

show more ...

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

c-api: component-model: Lookup function from an instance (#10675)

* c-api: component-model: Lookup function from an instance

* c-api: component-model: Take strings as `wasm_name_t`

* Use export in

c-api: component-model: Lookup function from an instance (#10675)

* c-api: component-model: Lookup function from an instance

* c-api: component-model: Take strings as `wasm_name_t`

* Use export indices

* Shared `CHECK_ERR` macro

* Pass names as a pointer and a size, return nullable pointers

* Use `std::str::from_utf8()` instead of `str::from_utf8()`

* Remove doc link?

show more ...

c-api: Module definitions in component model linker (#10651)

* c-api: Module definitions in component model linker

* Documentation and a test

c-api: Create and instantiate a component model linker (#10598)

* c-api: Create and instantiate a component model linker

Co-authored-by: Tyler Rockwood <[email protected]>
Co-authored-by: Jean-

c-api: Create and instantiate a component model linker (#10598)

* c-api: Create and instantiate a component model linker

Co-authored-by: Tyler Rockwood <[email protected]>
Co-authored-by: Jean-Jacques Lafay <[email protected]>

* c-api: Accept `wat` in `wasmtime_component_new()`

* Add a test

* c-api: Include `wasmtime/conf.h` in `component/component.h`

* Add `wasmtime/conf.h` include to `instance.h` and `linker.h`

* Make wasmtime_component_instance_t non-opaque

* Defer `wasmtime_component_linker_instance()`

---------

Co-authored-by: Tyler Rockwood <[email protected]>
Co-authored-by: Jean-Jacques Lafay <[email protected]>

show more ...