Point to component model instead of host bindings (#3746)

* Point to component model instead of host bindings (fixes #3143)

The original https://github.com/WebAssembly/host-bindings link in the doc
is indeed redirected to https://github.com/WebAssembly/interface-types,
which is the inactive one. There the "explainer" sheet says work moved to
https://github.com/WebAssembly/component-model.

Author: ydirson

guide/src/contributing/design/index.md

@@ -28,7 +28,7 @@ desired interface expressed in JS (classes, types, strings, etc) and the
 `foo_bg.wasm` module is simply used as an implementation detail (it was
 lightly modified from the original `foo.wasm` file).
 
-As more features are stabilized in WebAssembly over time (like host bindings)
+As more features are stabilized in WebAssembly over time (like component model)
 the JS file is expected to get smaller and smaller. It's unlikely to ever
 disappear, but `wasm-bindgen` is designed to follow the WebAssembly spec and
 proposals closely to optimize JS/Rust as much as possible.
@@ -59,9 +59,9 @@ pub fn greet(name: &str) -> String {
 ```
 
 Additionally the design here with minimal intervention in Rust should allow us
-to easily take advantage of the upcoming [host bindings][host] proposal. Ideally
+to easily take advantage of the upcoming [component model][component-model] proposal. Ideally
 you'd simply upgrade `wasm-bindgen`-the-crate as well as your toolchain and
-you're immediately getting raw access to host bindings! (this is still a bit of
+you're immediately getting raw access to component model! (this is still a bit of
 a ways off though...)
 
-[host]: https://github.com/WebAssembly/host-bindings
+[component-model]: https://github.com/WebAssembly/component-model

guide/src/introduction.md

@@ -7,8 +7,8 @@ ecosystem][rustwasm]. If you're not familiar already with `wasm-bindgen` it's
 recommended to start by reading the [Game of Life tutorial][gol]. If you're
 curious about `wasm-pack`, you can find that [documentation here][wasm-pack].
 
-The `wasm-bindgen` tool is sort of half polyfill for features like the [host
-bindings proposal][host] and half features for empowering high-level
+The `wasm-bindgen` tool is sort of half polyfill for features like the
+[component model proposal][component-model] and half features for empowering high-level
 interactions between JS and wasm-compiled code (currently mostly from Rust).
 More specifically this project allows JS/wasm to communicate with strings, JS
 objects, classes, etc, as opposed to purely integers and floats. Using
@@ -33,7 +33,7 @@ With the addition of [`wasm-pack`][wasm-pack] you can run the gamut from running
 the web locally, publishing it as part of a larger application, or even
 publishing Rust-compiled-to-WebAssembly on NPM!
 
-[host]: https://github.com/WebAssembly/host-bindings
+[component-model]: https://github.com/WebAssembly/component-model
 [dom-ex]: https://github.com/rustwasm/wasm-bindgen/tree/master/examples/dom
 [console-log]: https://github.com/rustwasm/wasm-bindgen/tree/master/examples/console_log
 [perf-ex]: https://github.com/rustwasm/wasm-bindgen/tree/master/examples/performance

guide/src/reference/attributes/on-js-imports/final.md

@@ -9,15 +9,15 @@ prototype chain of an object. Note that `final` is not suitable for accessing
 data descriptor properties of JS objects; to accomplish this, use the `structural`
 attribute.
 
-[host-bindings]: https://github.com/WebAssembly/host-bindings
+[component-model]: https://github.com/WebAssembly/component-model
 [reference-types]: https://github.com/WebAssembly/reference-types
 
 The `final` attribute is intended to be purely related to performance. It
 ideally has no user-visible effect, and `structural` imports (the default)
 should be able to transparently switch to `final` eventually.
 
-The eventual performance aspect is that with the [host bindings
-proposal][host-bindings] then `wasm-bindgen` will need to generate far fewer JS
+The eventual performance aspect is that with the [component model
+proposal][component-model] then `wasm-bindgen` will need to generate far fewer JS
 function shims to import than it does today. For example, consider this import
 today:
 
@@ -74,8 +74,8 @@ function with `getObject(arg0)` as the receiver.
 
 But wait, there's still a JS function shim here even with `final`! That's true,
 and this is simply a fact of future WebAssembly proposals not being implemented
-yet. The semantics, though, match the future [host bindings
-proposal][host-bindings] because the method being called is determined exactly
+yet. The semantics, though, match the future [component model
+proposal][component-model] because the method being called is determined exactly
 once, and it's located on the prototype chain rather than being resolved at
 runtime when the function is called.
 
@@ -106,14 +106,14 @@ export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
 }
 ```
 
-Getting better! Next up we need the host bindings proposal. Note that the
+Getting better! Next up we need the component model proposal. Note that the
 proposal is undergoing some changes right now so it's tough to link to reference
 documentation, but it suffices to say that it'll empower us with at least two
 different features.
 
-First, host bindings promises to provide the concept of "argument conversions".
+First, component model promises to provide the concept of "argument conversions".
 The `arg1` and `arg2` values here are actually a pointer and a length to a utf-8
-encoded string, and with host bindings we'll be able to annotate that this
+encoded string, and with component model we'll be able to annotate that this
 import should take those two arguments and convert them to a JS string (that is,
 the *host* should do this, the WebAssembly engine). Using that feature we can
 further trim this down to:
@@ -126,10 +126,10 @@ export function __wbg_bar_a81456386e6b526f(arg0, varg1) {
 }
 ```
 
-And finally, the second promise of the host bindings proposal is that we can
+And finally, the second promise of the component model proposal is that we can
 flag a function call to indicate the first argument is the `this` binding of the
 function call. Today the `this` value of all called imported functions is
-`undefined`, and this flag (configured with host bindings) will indicate the
+`undefined`, and this flag (configured with component model) will indicate the
 first argument here is actually the `this`.
 
 With that in mind we can further transform this to:
@@ -138,8 +138,8 @@ With that in mind we can further transform this to:
 export const __wbg_bar_a81456386e6b526f = Foo.prototype.bar;
 ```
 
-and voila! We, with [reference types][reference-types] and [host
-bindings][host-bindings], now have no JS function shim at all necessary to call
+and voila! We, with [reference types][reference-types] and [component
+model][component-model], now have no JS function shim at all necessary to call
 the imported function. Additionally future wasm proposals to the ES module
 system may also mean that don't even need the `export const ...` here too.