Update the README. (#218)

* Make `cargo component` consistent throughout.
* Remove section about Preview 2 not being stable.
* Update the rust-analyzer section to what `cargo component new` outputs.
* Remove mention of a macro being used by `cargo component`.

README.md

@@ -43,7 +43,7 @@ cargo install cargo-component
 ```
 
 If you have the [cargo-binstall](https://github.com/cargo-bins/cargo-binstall)
-utility installed, `cargo-component` can also be installed via a prebuilt
+utility installed, `cargo component` can also be installed via a prebuilt
 release artifact, saving time on the installation:
 
 ```
@@ -126,10 +126,10 @@ including Rust.
 `wit-bindgen` even provides procedural macros to generate the
 bindings "inline" with the component's source code.
 
-Like `wit-bindgen`, `cargo component` uses a procedural macro to generate
-bindings. However, bindings are generated based on the resolved dependencies
-from `Cargo.toml` rather than parsing a local definition of the component's
-interface.
+Unlike `wit-bindgen`, `cargo component` generates bindings directly into your
+project at `src/bindings.rs` so that bindings are generated based on the
+resolved dependencies from `Cargo.toml` rather than parsing a local definition
+of the component's interface.
 
 The hope is that one day (in the not too distant future...) that
 WebAssembly components might become an important part of the Rust
@@ -162,16 +162,12 @@ As this target is for a _preview1_ release of WASI, the WebAssembly module
 produced by the Rust compiler must be adapted to the _preview2_ version of WASI
 supported by the component model.
 
-The adaptation is automatically performed when `wasm32-wasi` is targeted using 
+The adaptation is automatically performed when `wasm32-wasi` is targeted using
 a built-in WASI adapter snapshotted out of the Wasmtime repository.
 
-As WASI preview2 has not stabilized yet, occasionally the output of 
-`cargo-component` may differ in its WASI interface definitions from a host 
-runtime like Wasmtime.
-
-When this occurs, you may override the built-in adapter `cargo-component` uses 
-by setting the `adapter` setting in the `[package.metadata.component]` table in 
-`Cargo.toml` to the path to the adapter module to use.
+You may override the built-in adapter `cargo component` uses by setting the
+`adapter` setting in the `[package.metadata.component]` table in `Cargo.toml`
+to the path to the adapter module to use.
 
 To build the adapter module, clone the [Wasmtime repository](https://github.com/bytecodealliance/wasmtime)
 and run the following commands:
@@ -189,7 +185,7 @@ cargo build -p wasi-preview1-component-adapter --target wasm32-unknown-unknown -
 cp target/wasm32-unknown-unknown/release/wasi_snapshot_preview1.wasm $PROJECT
 ```
 
-where `$REV` is the Wasmtime commit hash you want to use and `$PROJECT` is the 
+where `$REV` is the Wasmtime commit hash you want to use and `$PROJECT` is the
 path to your component project.
 
 Next, edit `Cargo.toml` to point at the adapter:
@@ -206,7 +202,7 @@ support in `cargo component` for adapting a _preview1_ module will be removed.
 
 ## Getting Started
 
-Use `cargo component new --lib <name>` to create a new library (reactor) 
+Use `cargo component new --lib <name>` to create a new library (reactor)
 component.
 
 A library component doesn't have a `run` (i.e. `main` in Rust) function
@@ -245,9 +241,9 @@ impl Guest for Component {
 }
 ```
 
-The `bindings` module contains the the types and traits that correspond to the 
-world targeted by the component; it is automatically generated by 
-`cargo-component`.
+The `bindings` module contains the the types and traits that correspond to the
+world targeted by the component; it is automatically generated by
+`cargo component`.
 
 ## Usage
 
@@ -287,11 +283,20 @@ To ensure that rust-analyzer is able to discover the latest bindings
 information, rust-analyzer must be configured to use `cargo component check` as
 the check command.
 
-To configure rust-analyzer to use the `cargo-component` executable, set the
+To configure rust-analyzer to use the `cargo component` executable, set the
 `rust-analyzer.check.overrideCommand` setting to the following:
 
 ```json
-"rust-analyzer.check.overrideCommand": ["cargo", "component", "check", "--message-format=json"]
+{
+    "rust-analyzer.check.overrideCommand": [
+        "cargo",
+        "component",
+        "check",
+        "--workspace",
+        "--all-targets",
+        "--message-format=json"
+    ],
+}
 ```
 
 By default, `cargo component new` will configure Visual Studio Code to use
@@ -345,6 +350,6 @@ changes on Windows, macOS, and Linux.
 
 Publication of this crate is entirely automated via CI. A publish happens
 whenever a tag is pushed to the repository, so to publish a new version you'll
-want to make a PR that bumps the version numbers (see the `ci/publish.rs` 
-script), merge the PR, then tag the PR and push the tag. That should trigger 
+want to make a PR that bumps the version numbers (see the `ci/publish.rs`
+script), merge the PR, then tag the PR and push the tag. That should trigger
 all that's necessary to publish all the crates and binaries to crates.io.