<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in path2_concurrent.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs#96e19700</link>
        <description>Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense

            List of files:
            /wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs</description>
        <pubDate>Wed, 07 Jan 2026 17:08:11 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>4dd4b890 - Fix(wit_bindgen): use declared defaults to decide on `Send` Bounds in `Wastime::world_add_to_linker` (#11761)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs#4dd4b890</link>
        <description>Fix(wit_bindgen): use declared defaults to decide on `Send` Bounds in `Wastime::world_add_to_linker` (#11761)* feat: make FonctionConfig.default pub(crate)Signed-off-by: Antoine Lavandier &lt;antoine.lavandier@inria.fr&gt;* fix: use declared imports/exports defaults when deciding on Send boundsSigned-off-by: Antoine Lavandier &lt;antoine.lavandier@inria.fr&gt;* fix: add Send bound on relevant test outputSigned-off-by: Antoine Lavandier &lt;antoine.lavandier@inria.fr&gt;* fix(tests): add test using imports to define send boundsSigned-off-by: Antoine Lavandier &lt;antoine.lavandier@inria.fr&gt;* fix(fmt): make rustfmt happySigned-off-by: Antoine Lavandier &lt;antoine.lavandier@inria.fr&gt;* fix(fmt): actually make rustfmt happy this timeSigned-off-by: Antoine Lavandier &lt;antoine.lavandier@inria.fr&gt;---------Signed-off-by: Antoine Lavandier &lt;antoine.lavandier@inria.fr&gt;

            List of files:
            /wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs</description>
        <pubDate>Wed, 01 Oct 2025 14:15:35 +0000</pubDate>
        <dc:creator>anlavandier &lt;90333202+anlavandier@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>1155d6df - Redesign function configuration in `bindgen!` (#11328)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs#1155d6df</link>
        <description>Redesign function configuration in `bindgen!` (#11328)* Redesign function configuration in `bindgen!`This commit is a redesign of how function-level configuration works inWasmtime&apos;s `bindgen!` macro. The main goal of this redesign is tobetter support WASIp3 and component model async functions. Prior to thisredesign there was a mish mash of mechanisms to configure behavior ofimports/exports:* The `async` configuration could turn everything async, nothing async,  only some imports async, or everything except some imports async.* The `concurrent_{imports,exports}` keys were required to explicitly  opt-in to component model async signatures and applied to all  imports/exports.* The `trappable_imports` configuration would indicate a list of imports  allowed to trap and it had special configuration for everything,  nothing, and only a certain list.* The `tracing` and `verbose_tracing` keys could be applied to either  nothing or all functions.Overall the previous state of configuration in `bindgen!` was clearly ahodgepodge of systems that organically grew over time. In my personalopinion it was in dire need of a refresh to take into account howcomponent-model-async ended up being implemented as well asconsolidating the one-off systems amongst all of these configurationkeys. A major motivation of this redesign, for example, was to inheritbehavior from WIT files by default. An `async` function in WIT shouldnot require `concurrent_*` keys to be configured, but rather it shouldgenerate correct bindings by default.In this commit, all of the above keys were removed. All keys have beenreplaced with `imports` and `exports` configuration keys. Each behavesthe same way and looks like so:    bindgen!({        // ...        imports: {            // enable tracing for just this function            &quot;my:local/interface/func&quot;: tracing,            // enable verbose tracing for just this function            &quot;my:local/interface/other-func&quot;: tracing | verbose_tracing,            // this is blocking in WIT, but generate async bindings for            // it            &quot;my:local/interface/[method]io.block&quot;: async,            // like above, but use &quot;concurrent&quot; bindings which have            // access to the store.            &quot;my:local/interface/[method]io.block-again&quot;: async | store,            // everything else is, by default, trappable            default: trappable,        },    });Effectively all the function-level configuration items are now bitflags.These bitflags are by default inherited from the WIT files itself (e.g.`async` functions are `async | store` by default). Further configurationis then layered on top at the desires of the embedder. Supported keys are:* `async` - this means that a Rust-level `async` function should be  generated. This is either `CallStyle::Async` or  `CallStyle::Concurrent` as it was prior, depending on ...* `store` - this means that the generated function will have access to  the store on the host. This is only implemented right now for `async |  store` functions which map to `CallStyle::Concurrent`. In the future  I&apos;d like to support just-`store` functions which means that you could  define a synchronous function with access to the store in addition to  an asynchronous function.* `trappable` - this means that the function returns a  `wasmtime::Result&lt;TheWitBindingType&gt;`. If `trappable_errors` is  applicable then it means just a `Result&lt;TheWitOkType,  TrappableErrorType&gt;` is returned (like before)* `tracing` - this enables `tracing!` integration for this function.* `verbose_tracing` - this logs all argument values for this function  (including lists).* `ignore_wit` - this ignores the WIT-level defaults of the function  (e.g. ignoring WIT `async`).The way this then works is all modeled is that for any WIT functionbeing generated there are a set of flags associated with that function.To calculate the flags the algorithm looks like:1. Find the first matching rule in the `imports` or `exports` map   depending on if the function is imported or exported. If there is no   matching rule then use the `default` rule if present. This is the   initial set of flags for the function (or empty if nothing was   found).2. If `ignore_wit` is present, return the flags from step 1. Otherwise   add in `async | store` if the function is `async` in WIT.The resulting set of flags are then used to control how everything isgenerated. For example the same split traits of today are stillgenerated and it&apos;s controlled based on the flags. Note though that theprevious `HostConcurrent` trait was renamed to `HostWithStore` to makespace for synchronous functions in this trait in the future too.The end result of all these changes is that configuring imports/exportsnow uses the exact same selection system as the `with` replacement map,meaning there&apos;s only one system of selecting functions instead of 3.WIT-level `async` is now respected by default meaning that bindings workby default without further need to configure anything (unless morefunctionality is desired).One final minor change made here as well is that auto-generated`instantiate` methods are now always synchronous and an`instantiate_async` method is unconditionally generated for async mode.This means that bindings always generate both functions and it&apos;s up tothe embedder to choose the appropriate one.Closes #11246Closes #11247* Update expanded test expectationsprtest:full* Fix the min platform embedding example* Fix doc tests* Always generate `*WithStore` traitsThis helps when using the `with` mapping since that can always assumethat `HostWithStore` is available in the generated bindings, avoidingthe need to duplicate configuration options.* Update test expectations* Review comments

            List of files:
            /wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs</description>
        <pubDate>Mon, 28 Jul 2025 18:31:06 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>beca86b0 - Re-enable concurrent bindings generation tests  (#10972)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs#beca86b0</link>
        <description>Re-enable concurrent bindings generation tests  (#10972)* Re-enable concurrent bindings generation testsThis commit re-enables tests for bindings generation for concurrentcalls in the main repo after all syncs have now finished with wasip3.This additionally adds some skeleton APIs that the bindings generatoruses which are necessary to get tests passing.* Update test expectations

            List of files:
            /wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs</description>
        <pubDate>Mon, 09 Jun 2025 14:15:18 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>f81c0dc0 - Add `T: &apos;static` to `Store&lt;T&gt;` (#10760)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs#f81c0dc0</link>
        <description>Add `T: &apos;static` to `Store&lt;T&gt;` (#10760)* Add `T: &apos;static` to `Store&lt;T&gt;Since the beginning the `T` type parameter on `Store&lt;T&gt;` has had nobounds on it. This was intended for maximal flexibility in terms of whatembedders place within a `Store&lt;T&gt;` and I&apos;ve personally advocated thatwe need to keep it this way. In the development of the WASIp3 work,however, I&apos;ve at least personally reached the conclusion that this is nolonger tenable and proceeding will require adding a `&apos;static` bound todata within a store.Wasmtime today [already] carries unsafe `transmute`s to work around thislack of `&apos;static` bound, and while the number of `unsafe` parts isrelatively small right now we&apos;re still fundamentally lying to thecompiler about lifetime bounds internally. With the WASIp3 async workthis degree of &quot;lying&quot; has become even worse. Joel has written up someexamples [on Zulip] about how the Rust compiler is requiring `&apos;static`bounds in surprising ways. These patterns are cropping up quitefrequently in the WASIp3 work and it&apos;s becoming particularly onerousmaintaining all of the `unsafe` and ensuring that everything is in sync.In the WASIp3 repository I&apos;ve additionally [prototyped a change] whichwould additionally practically require `T: &apos;static` in more locations.This change is one I plan on landing in Wasmtime in the near future andwhile its main motivations are for enabling WASIp3 work it is also amuch nicer system than what we have today, in my opinion.Overall the cost of not having `T: &apos;static` on `Store&lt;T&gt;` is effectivelybecoming quite costly, in particular with respect to WASIp3 work. Thisis coupled with all known embedders already using `T: &apos;static` datawithin a `Store&lt;T&gt;` so the expectation of the impact of this change isnot large. The main downside of this change as a result is that when andwhere to place `&apos;static` bounds is sort of a game of whack-a-mole withthe compiler. For example I changed `Store&lt;T&gt;` to require `&apos;static`here, but the rest of the change is basically &quot;hit compile until rustcsays it&apos;s ok&quot;. There&apos;s not necessarily a huge amount of rhyme-or-reasonto where `&apos;static` bounds crop up, which can be surprising or difficultto work with for users.In the end I feel that this change is necessary and one we can&apos;t shyaway from. If problems crop up we&apos;ll need to figure out how to threadthat needle at that time, but I&apos;m coming around to thinking that`T: &apos;static` is just a fundamental constraint we&apos;ll have to take on atthis time. Maybe a future version of Rust that fixes some of Joel&apos;sexamples (if they can be fixed, we&apos;re not sure of that) we couldconsider relaxing this but that&apos;s left for future work.[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158* Remove a no-longer-necessary `unsafe` block* Update test expectations* Fix gc-disabled builds

            List of files:
            /wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs</description>
        <pubDate>Tue, 13 May 2025 05:08:32 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>29d04b15 - Move the `GetHost` trait used in `bindgen!` into Wasmtime (#10746)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs#29d04b15</link>
        <description>Move the `GetHost` trait used in `bindgen!` into Wasmtime (#10746)* Move the `GetHost` trait used in `bindgen!` into WasmtimeTurns out we don&apos;t actually need to generate this `GetHost` trait, wecan instead have it live in one location with extra documentation. Thereare already extra bounds on the `Host` associated type at all call-sitesso there&apos;s no need to additionally have trait bounds in the traitdefinition, meaning the trait definition is always the same and it canmove within Wasmtime.This shouldn&apos;t have any impact on any embedders today, it&apos;s just movingthings around.* Review comments

            List of files:
            /wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs</description>
        <pubDate>Wed, 07 May 2025 21:02:44 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>bb77f602 - wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction (#10610)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs#bb77f602</link>
        <description>wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction (#10610)* wasmtime::component: make it possible to typecheck export funcs* wasmtime-wit-bindgen: add typechecking on construction of Indices struct* wit-bindgen: reduce to a single Indices constructor which takes InstancePre* bless bindgen output

            List of files:
            /wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs</description>
        <pubDate>Mon, 21 Apr 2025 21:54:01 +0000</pubDate>
        <dc:creator>Pat Hickey &lt;p.hickey@f5.com&gt;</dc:creator>
    </item>
<item>
        <title>636435f1 - async/stream/future support for wasmtime-wit-bindgen (#10044)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs#636435f1</link>
        <description>async/stream/future support for wasmtime-wit-bindgen (#10044)* async/stream/future support for wasmtime-wit-bindgenI&apos;ve split this out of #9582 to make review easier.This patch adds async/stream/future/error-context support to the host bindinggenerator, along with placeholder type and function definitions in the`wasmtime` crate which the generated bindings can refer to.  Seehttps://github.com/dicej/rfcs/blob/component-async/accepted/component-model-async.md#componentbindgen-updatesfor the design and rationale.Note that I&apos;ve added temporary `[patch.crates-io]` overrides in Cargo.toml untilhttps://github.com/bytecodealliance/wit-bindgen/pull/1130 andhttps://github.com/bytecodealliance/wasm-tools/pull/1978 have been released.Also note that we emit a `T: &apos;static` bound for `AsContextMut&lt;Data = T&gt;` whengenerating bindings with `concurrent_imports: true`.  This is only because`rustc` insists that the closure we&apos;re passing to`LinkerInstance::func_wrap_concurrent` captures the lifetime of `T` despite mybest efforts to convince it otherwise.  Alex and I suspect this is a limitationin the compiler, and I asked about it on the rust-lang Zulip, but we haven&apos;tbeen able to determine a workaround so far.Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;remove obsolete TODO commentSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;make `futures` dep optionalSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;update `wasm-tools` and `wit-bindgen`Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;* run cargo vetSigned-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;---------Signed-off-by: Joel Dice &lt;joel.dice@fermyon.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/component-macro/tests/expanded/path2_concurrent.rs</description>
        <pubDate>Wed, 22 Jan 2025 17:19:46 +0000</pubDate>
        <dc:creator>Joel Dice &lt;joel.dice@fermyon.com&gt;</dc:creator>
    </item>
</channel>
</rss>
