<?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 linking.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>4ac219fd - Rename &quot;preview{0,1}&quot; in `wasmtime-wasi` to &quot;p{0,1}&quot; (#11380)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#4ac219fd</link>
        <description>Rename &quot;preview{0,1}&quot; in `wasmtime-wasi` to &quot;p{0,1}&quot; (#11380)* Rename &quot;preview{0,1}&quot; in `wasmtime-wasi` to &quot;p{0,1}&quot;This commit renames the `preview1` module and features to `p1` and doesthe same for `preview0`. This additionally cleans up the test suite abit to share more code amongst all the implementaitons and to also movethe p1 tests out of the p2 folder.This additionally adds a `p2` feature to the `wasmtime-wasi` crate butit does not currently gate the `p2` module because that&apos;ll require somemore refactoring an annotations to get that working.* Fix build of the CLI* Fix build of the C API* Fix bench-api build* Fix build of examples* More renamings

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Tue, 05 Aug 2025 18:48:22 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>f7a5aa34 - Unify WASIp{2,3} context structures (#11370)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#f7a5aa34</link>
        <description>Unify WASIp{2,3} context structures (#11370)This removes `wasmtime_wasi::p{2,3}::{WasiCtx, WasiCtxBuilder,WasiView}` in favor of only having `wasmtime_wasi::{WasiCtx,WasiCtxBuilder, WasiView}` instead. Conceptually these revisions of WASIall provide the same functionality just with a different veneer that thecomponent model offers, so having only one way to configure host-sidebehavior will make it easier to both organize implementations internally(e.g. more sharing of code) as well as for embedders to configure (onlyone context to create/manage).

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Sat, 02 Aug 2025 00:57:09 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>9ce3ffe1 - Update some CI dependencies (#7983)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#9ce3ffe1</link>
        <description>Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Thu, 22 Feb 2024 23:54:03 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>2b00a541 - Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#2b00a541</link>
        <description>Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)* WIP: try to make wasi-common self contained.* rebase: cargo.lock* remove all dependencies between wasi-common and wasmtime-wasi* use wasi-common directly throughout tests, benches, examples, cli run* wasi-threads: use wasi-common&apos;s maybe_exit_on_error in spawned threadnot a very modular design, but at this point wasi-common andwasi-threads are forever wed* fix wasmtime&apos;s docs* re-introduce wasmtime-wasi&apos;s exports of wasi-common definitions behind deprecated* factor out determining i32 process exit codeand remove libc dep because rustix provides the same constant* commands/run: inline the logic about aborting on trapsince this is the sole place in the codebase its used* Add high-level summary to wasi-common&apos;s top-level doc comment.* c-api: fix use of wasi_cap_std_sync =&gt; wasi_common::sync, wasmtime_wasi =&gt; wasi_common* fix tokio example* think better of combining downcast and masking into one method* fix references to wasmtime_wasi in docsprtest:full* benches: use wasi-common* cfg-if around use of rustix::process because that doesnt exist on windows* wasi-common: include tests, caught by verify-publish* fix another bench* exit requires wasmtime dep. caught by verify-publish.

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Tue, 13 Feb 2024 17:57:58 +0000</pubDate>
        <dc:creator>Pat Hickey &lt;phickey@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>b0939f66 - Remove explicit `S` type parameters (#5275)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#b0939f66</link>
        <description>Remove explicit `S` type parameters (#5275)* Remove explicit `S` type parametersThis commit removes the explicit `S` type parameter on `Func::typed` and`Instance::get_typed_func`. Historical versions of Rust required thatthis be a type parameter but recent rustcs support a mixture of explicittype parameters and `impl Trait`. This removes, at callsites, asuperfluous `, _` argument which otherwise never needs specification.* Fix mdbook examples

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Wed, 16 Nov 2022 05:04:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>7a1b7cdf - Implement RFC 11: Redesigning Wasmtime&apos;s APIs (#2897)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#7a1b7cdf</link>
        <description>Implement RFC 11: Redesigning Wasmtime&apos;s APIs (#2897)Implement Wasmtime&apos;s new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it&apos;s best to read the RFC thread and the PR thread.

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Thu, 03 Jun 2021 14:10:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>0f5bdc64 - only wasi_cap_std_sync and wasi_tokio need to define WasiCtxBuilders (#2917)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#0f5bdc64</link>
        <description>only wasi_cap_std_sync and wasi_tokio need to define WasiCtxBuilders (#2917)* wasmtime-wasi: re-exporting this WasiCtxBuilder was shadowing the right onewasi-common&apos;s WasiCtxBuilder is really only useful wasi_cap_std_sync andwasi_tokio to implement their own Builder on top of.This re-export of wasi-common&apos;s is 1. not useful and 2. shadow&apos;s there-export of the right one in sync::*.* wasi-common: eliminate WasiCtxBuilder, make the builder methods on WasiCtx instead* delete wasi-common::WasiCtxBuilder altogetherjust put those methods directly on &amp;mut WasiCtx.As a bonus, the sync and tokio WasiCtxBuilder::build functionsare no longer fallible!* bench fixes* more test fixes

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Fri, 21 May 2021 17:59:39 +0000</pubDate>
        <dc:creator>Pat Hickey &lt;phickey@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>c691d186 - fix</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#c691d186</link>
        <description>fix

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Wed, 14 Apr 2021 16:54:27 +0000</pubDate>
        <dc:creator>Pat Hickey &lt;pat@moreproductive.org&gt;</dc:creator>
    </item>
<item>
        <title>ae4c5a9d - fixes in tests and examples</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#ae4c5a9d</link>
        <description>fixes in tests and examples

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Fri, 26 Mar 2021 22:37:57 +0000</pubDate>
        <dc:creator>Pat Hickey &lt;pat@moreproductive.org&gt;</dc:creator>
    </item>
<item>
        <title>2697a18d - Redo the statically typed `Func` API (#2719)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#2697a18d</link>
        <description>Redo the statically typed `Func` API (#2719)* Redo the statically typed `Func` APIThis commit reimplements the `Func` API with respect to statically typeddispatch. Previously `Func` had a `getN` and `getN_async` family ofmethods which were implemented for 0 to 16 parameters. The return valueof these functions was an `impl Fn(..)` closure with the appropriateparameters and return values.There are a number of downsides with this approach that have becomeapparent over time:* The addition of `*_async` doubled the API surface area (which is quite  large here due to one-method-per-number-of-parameters).* The [documentation of `Func`][old-docs] are quite verbose and feel  &quot;polluted&quot; with all these getters, making it harder to understand the  other methods that can be used to interact with a `Func`.* These methods unconditionally pay the cost of returning an owned `impl  Fn` with a `&apos;static` lifetime. While cheap, this is still paying the  cost for cloning the `Store` effectively and moving data into the  closed-over environment.* Storage of the return value into a struct, for example, always  requires `Box`-ing the returned closure since it otherwise cannot be  named.* Recently I had the desire to implement an &quot;unchecked&quot; path for  invoking wasm where you unsafely assert the type signature of a wasm  function. Doing this with today&apos;s scheme would require doubling  (again) the API surface area for both async and synchronous calls,  further polluting the documentation.The main benefit of the previous scheme is that by returning a `impl Fn`it was quite easy and ergonomic to actually invoke the function. Inpractice, though, examples would often have something akin to`.get0::&lt;()&gt;()?()?` which is a lot of things to interpret all at once.Note that `get0` means &quot;0 parameters&quot; yet a type parameter is passed.There&apos;s also a double function invocation which looks like a lot ofcharacters all lined up in a row.Overall, I think that the previous design is starting to show too manycracks and deserves a rewrite. This commit is that rewrite.The new design in this commit is to delete the `getN{,_async}` family offunctions and instead have a new API:    impl Func {        fn typed&lt;P, R&gt;(&amp;self) -&gt; Result&lt;&amp;Typed&lt;P, R&gt;&gt;;    }    impl Typed&lt;P, R&gt; {        fn call(&amp;self, params: P) -&gt; Result&lt;R, Trap&gt;;        async fn call_async(&amp;self, params: P) -&gt; Result&lt;R, Trap&gt;;    }This should entirely replace the current scheme, albeit by slightlylosing ergonomics use cases. The idea behind the API is that theexistence of `Typed&lt;P, R&gt;` is a &quot;proof&quot; that the underlying functiontakes `P` and returns `R`. The `Func::typed` method peforms a runtimetype-check to ensure that types all match up, and if successful you geta `Typed` value. Otherwise an error is returned.Once you have a `Typed` then, like `Func`, you can either `call` or`call_async`. The difference with a `Typed`, however, is that theparams/results are statically known and hence these calls can be muchmore efficient.This is a much smaller API surface area from before and should greatlysimplify the `Func` documentation. There&apos;s still a problem where`Func::wrapN_async` produces a lot of functions to document, but that&apos;snow the sole offender. It&apos;s a nice benefit that thestatically-typed-async verisons are now expressed with an `async`function rather than a function-returning-a-future which makes it bothmore efficient and easier to understand.The type `P` and `R` are intended to either be bare types (e.g. `i32`)or tuples of any length (including 0). At this time `R` is only allowedto be `()` or a bare `i32`-style type because multi-value is notsupported with a native ABI (yet). The `P`, however, can be any size oftuples of parameters. This is also where some ergonomics are lostbecause instead of `f(1, 2)` you now have to write `f.call((1, 2))`(note the double-parens). Similarly `f()` becomes `f.call(())`.Overall I feel that this is a better tradeoff than before. While notuniversally better due to the loss in ergonomics I feel that this designis much more flexible in terms of what you can do with the return valueand also understanding the API surface area (just less to take in).[old-docs]: https://docs.rs/wasmtime/0.24.0/wasmtime/struct.Func.html#method.get0* Rename Typed to TypedFunc* Implement multi-value returns through `Func::typed`* Fix examples in docs* Fix some more errors* More test fixes* Rebasing and adding `get_typed_func`* Updating tests* Fix typo* More doc tweaks* Tweak visibility on `Func::invoke`* Fix tests again

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Thu, 11 Mar 2021 20:43:34 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>2ad7565a - update linking example</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#2ad7565a</link>
        <description>update linking example

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Fri, 29 Jan 2021 23:39:29 +0000</pubDate>
        <dc:creator>Pat Hickey &lt;pat@moreproductive.org&gt;</dc:creator>
    </item>
<item>
        <title>15c68f2c - Disconnects `Store` state fields from `Compiler` (#1761)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#15c68f2c</link>
        <description>Disconnects `Store` state fields from `Compiler` (#1761)*  Moves CodeMemory, VMInterrupts and SignatureRegistry from Compiler*  CompiledModule holds CodeMemory and GdbJitImageRegistration*  Store keeps track of its JIT code*  Makes &quot;jit_int.rs&quot; stuff Send+Sync*  Adds the threads example.

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Tue, 02 Jun 2020 18:44:39 +0000</pubDate>
        <dc:creator>Yury Delendik &lt;ydelendik@mozilla.com&gt;</dc:creator>
    </item>
<item>
        <title>9364eb1d - Refactor (#1524)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#9364eb1d</link>
        <description>Refactor (#1524)* Compute instance exports on demand.Instead having instances eagerly compute a Vec of Externs, and bumpingthe refcount for each Extern, compute Externs on demand.This also enables `Instance::get_export` to avoid doing a linear search.This also means that the closure returned by `get0` and friends nowholds an `InstanceHandle` to dynamically hold the instance live ratherthan being scoped to a lifetime.* Compute module imports and exports on demand too.And compute Extern::ty on demand too.* Add a utility function for computing an ExternType.* Add a utility function for looking up a function&apos;s signature.* Add a utility function for computing the ValType of a Global.* Rename wasmtime_environ::Export to EntityIndex.This helps differentiate it from other Export types in the tree, anddescribes what it is.* Fix a typo in a comment.* Simplify module imports and exports.* Make `Instance::exports` return the export names.This significantly simplifies the public API, as it&apos;s relatively commonto need the names, and this avoids the need to do a zip with`Module::exports`.This also changes `ImportType` and `ExportType` to have public membersinstead of private members and accessors, as I find that simplifies theusage particularly in cases where there are temporary instances.* Remove `Instance::module`.This doesn&apos;t quite remove `Instance`&apos;s `module` member, it gets a stepcloser.* Use a InstanceHandle utility function.* Don&apos;t consume self in the `Func::get*` methods.Instead, just create a closure containing the instance handle and theexport for them to call.* Use `ExactSizeIterator` to avoid needing separate `num_*` methods.* Rename `Extern::func()` etc. to `into_func()` etc.* Revise examples to avoid using `nth`.* Add convenience methods to instance for getting specific extern types.* Use the convenience functions in more tests and examples.* Avoid cloning strings for `ImportType` and `ExportType`.* Remove more obviated clone() calls.* Simplify `Func`&apos;s closure state.* Make wasmtime::Export&apos;s fields private.This makes them more consistent with ExportType.* Fix compilation error.* Make a lifetime parameter explicit, and use better lifetime names.Instead of &apos;me, use &apos;instance and &apos;module to make it clear what thelifetime is.* More lifetime cleanups.

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Mon, 20 Apr 2020 20:55:33 +0000</pubDate>
        <dc:creator>Dan Gohman &lt;sunfish@mozilla.com&gt;</dc:creator>
    </item>
<item>
        <title>0d4bde4a - Add a `wasmtime::Linker` type (#1384)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#0d4bde4a</link>
        <description>Add a `wasmtime::Linker` type (#1384)* Add a `wasmtime::Linker` typeThis commit adds a new type to the `wasmtime` crate, a `Linker`. Thislinker is intended to vastly simplify calling `Instance::new` by easilyperforming name resolution and incrementally defining state over time.The goal here is to start down a path of making linking wasm modules in`wasmtime` a first-class and ergonomic operation. This is highly likelyto evolve over time and get tweaked through releases as we iteratetowards a design well-suited for `wasmtime`, but this is intended to atleast be the initial foundation for such functionality.This commit additionally also adds a C API for the linker and switchesthe existing linking examples to using this linker in both Rust and C.One piece of future work I&apos;d like to tackle next is to integrate WASIinto the `wasmtime` crate in a more first-class manner. This [`Linker`]type provides a great location to hook into the instantiation process toeasily instantiate modules with WASI imports. That&apos;s a relatively largerefactoring for now though and I figured it&apos;d be best left for adifferent time.Closes #727

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Tue, 24 Mar 2020 02:02:31 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>e245e6dd - Add examples of linking and WASI (#1369)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/linking.rs#e245e6dd</link>
        <description>Add examples of linking and WASI (#1369)* Add examples of linking and WASIThis commit adds two example programs, one for linking two modulestogether and one for instantiating WASI. The linkage exampleadditionally uses WASI to get some meaningful output at this time.cc #1272* Add examples to the book as well* More links!* Ignore examples from rustdoc testsing* More example updates* More ignored

            List of files:
            /wasmtime-44.0.1/examples/linking.rs</description>
        <pubDate>Fri, 20 Mar 2020 23:10:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
