|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3 |
|
| #
c09aa380 |
| 03-Feb-2026 |
Joel Dice <[email protected]> |
deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)
* deprecate `[Typed]Func::post_return[_async]` and make them no-ops
With the advent of the Component Model concurrency ABI
deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)
* deprecate `[Typed]Func::post_return[_async]` and make them no-ops
With the advent of the Component Model concurrency ABI and it's `task.return` intrinsic, post-return functions have been informally deprecated and are expected to be removed for WASI 1.0 and the corresponding stable edition of the Component Model. Consequently, it does not make sense anymore to require embedders to explicitly call the post-return function after using `[Typed]Func::call[_async]`.
As of this commit, `[Typed]Func::post_return[_async]` are no-ops. Instead, the post-return function is called automatically as part of `[Typed]Func::call[_async]` if present, which is how `[Typed]Func::call_concurrent` has worked all along. In addition, this commit fixes and tests a couple of cases where the task and/or thread was being disposed of before the post-return function was called.
* address review feedback
* test post-return function in more scenarios
Specifically, I've split the `invoke_post_return` test into multiple tests:
- using `TypedFunc::call` - using `TypedFunc::call_async` with concurrency support enabled - using `TypedFunc::call_async` with concurrency support disabled - using `Func::call_async` with concurrency support disabled - using `TypedFunc::call_concurrent`
* remove GCC/clang-specific deprecation attribute
This broke the MSVC build.
* bless bindgen output
* remove obsolete post-return functions and fields
Now that post-return calls are handled internally without requiring explicit action by the embedder, we can avoid unnecessary bookkeeping.
show more ...
|
|
Revision tags: v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5 |
|
| #
39ec36ca |
| 05-Nov-2025 |
Alex Crichton <[email protected]> |
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 ...
|
|
Revision tags: v38.0.3 |
|
| #
dbc21cde |
| 22-Oct-2025 |
Alex Crichton <[email protected]> |
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 ...
|
|
Revision tags: v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0 |
|
| #
53701b21 |
| 27-May-2025 |
MangoPeachGrape <[email protected]> |
c-api: component-model: Function post return, more values (#10841)
* c-api: component-model: `wasmtime_component_post_return()`
* c-api: component-model: Tuple values
* c-api: component-model: Var
c-api: component-model: Function post return, more values (#10841)
* c-api: component-model: `wasmtime_component_post_return()`
* c-api: component-model: Tuple values
* c-api: component-model: Variant values
This required `wasmtime_component_val_new()`
show more ...
|
| #
b2c64de1 |
| 23-May-2025 |
MangoPeachGrape <[email protected]> |
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 ...
|