From e1c87e2e7bb0f6a1362af7a6189dae961dd70106 Mon Sep 17 00:00:00 2001
From: Mikhail Katychev <mkatych@gmail.com>
Date: Wed, 29 Jan 2025 15:26:19 -0600
Subject: [PATCH 1/2] normalize all wit codeblocks

---
 design/mvp/CanonicalABI.md                    | 54 ++++++------
 design/mvp/Explainer.md                       | 88 +++++++++----------
 design/mvp/WIT.md                             | 16 ++--
 design/mvp/examples/LinkTimeVirtualization.md |  8 +-
 .../SharedEverythingDynamicLinking.md         | 12 +--
 5 files changed, 89 insertions(+), 89 deletions(-)

diff --git a/design/mvp/CanonicalABI.md b/design/mvp/CanonicalABI.md
index af38fdef..5b089e3e 100644
--- a/design/mvp/CanonicalABI.md
+++ b/design/mvp/CanonicalABI.md
@@ -2703,7 +2703,7 @@ cover each of these `canon` cases.
 ### `canon lift`
 
 For a canonical definition:
-```wasm
+```wat
 (canon lift $callee:<funcidx> $opts:<canonopt>* (func $f (type $ft)))
 ```
 validation specifies:
@@ -2866,7 +2866,7 @@ async def call_and_trap_on_throw(callee, task, args):
 ### `canon lower`
 
 For a canonical definition:
-```wasm
+```wat
 (canon lower $callee:<funcidx> $opts:<canonopt>* (core func $f))
 ```
 where `$callee` has type `$ft`, validation specifies:
@@ -3016,7 +3016,7 @@ as post-MVP [adapter functions].
 ### `canon resource.new`
 
 For a canonical definition:
-```wasm
+```wat
 (canon resource.new $rt (core func $f))
 ```
 validation specifies:
@@ -3039,7 +3039,7 @@ async def canon_resource_new(rt, task, rep):
 ### `canon resource.drop`
 
 For a canonical definition:
-```wasm
+```wat
 (canon resource.drop $rt $async? (core func $f))
 ```
 validation specifies:
@@ -3093,7 +3093,7 @@ destructor is an encapsualted implementation detail of the resource type.
 ### `canon resource.rep`
 
 For a canonical definition:
-```wasm
+```wat
 (canon resource.rep $rt (core func $f))
 ```
 validation specifies:
@@ -3116,7 +3116,7 @@ component instance defining a resource can access its representation.
 ### 🔀 `canon context.get`
 
 For a canonical definition:
-```wasm
+```wat
 (canon context.get $t $i (core func $f))
 ```
 validation specifies:
@@ -3137,7 +3137,7 @@ async def canon_context_get(t, i, task):
 ### 🔀 `canon context.set`
 
 For a canonical definition:
-```wasm
+```wat
 (canon context.set $t $i (core func $f))
 ```
 validation specifies:
@@ -3159,7 +3159,7 @@ async def canon_context_set(t, i, task, v):
 ### 🔀 `canon backpressure.set`
 
 For a canonical definition:
-```wasm
+```wat
 (canon backpressure.set (core func $f))
 ```
 validation specifies:
@@ -3181,7 +3181,7 @@ consume resources.
 ### 🔀 `canon task.return`
 
 For a canonical definition:
-```wasm
+```wat
 (canon task.return (result $t)? $opts (core func $f))
 ```
 validation specifies:
@@ -3212,7 +3212,7 @@ a thunk that is indirectly called by `task.return` after these guards.
 ### 🔀 `canon yield`
 
 For a canonical definition:
-```wasm
+```wat
 (canon yield $async? (core func $f))
 ```
 validation specifies:
@@ -3240,7 +3240,7 @@ activations.
 ### 🔀 `canon waitable-set.new`
 
 For a canonical definition:
-```wasm
+```wat
 (canon waitable-set.new (core func $f))
 ```
 validation specifies:
@@ -3258,7 +3258,7 @@ async def canon_waitable_set_new(task):
 ### 🔀 `canon waitable-set.wait`
 
 For a canonical definition:
-```wasm
+```wat
 (canon waitable-set.wait $async? (memory $mem) (core func $f))
 ```
 validation specifies:
@@ -3302,7 +3302,7 @@ handle multiple overlapping callback activations.
 ### 🔀 `canon waitable-set.poll`
 
 For a canonical definition:
-```wasm
+```wat
 (canon waitable-set.poll $async? (memory $mem) (core func $f))
 ```
 validation specifies:
@@ -3333,7 +3333,7 @@ activations.
 ### 🔀 `canon waitable-set.drop`
 
 For a canonical definition:
-```wasm
+```wat
 (canon waitable-set.drop (core func $f))
 ```
 validation specifies:
@@ -3354,7 +3354,7 @@ async def canon_waitable_set_drop(task, i):
 ### 🔀 `canon waitable.join`
 
 For a canonical definition:
-```wasm
+```wat
 (canon waitable.join (core func $f))
 ```
 validation specifies:
@@ -3380,7 +3380,7 @@ given waitable is already in one set, it will be transferred.
 ### 🔀 `canon subtask.drop`
 
 For a canonical definition:
-```wasm
+```wat
 (canon subtask.drop (core func $f))
 ```
 validation specifies:
@@ -3402,7 +3402,7 @@ async def canon_subtask_drop(task, i):
 ### 🔀 `canon {stream,future}.new`
 
 For canonical definitions:
-```wasm
+```wat
 (canon stream.new $t (core func $f))
 (canon future.new $t (core func $f))
 ```
@@ -3432,7 +3432,7 @@ the future built-ins below.
 ### 🔀 `canon {stream,future}.{read,write}`
 
 For canonical definitions:
-```wasm
+```wat
 (canon stream.read $t $opts (core func $f))
 (canon stream.write $t $opts (core func $f))
 ```
@@ -3440,7 +3440,7 @@ validation specifies:
 * `$f` is given type `(func (param i32 i32 i32) (result i32))`
 
 For canonical definitions:
-```wasm
+```wat
 (canon future.read $t $opts (core func $f))
 (canon future.write $t $opts (core func $f))
 ```
@@ -3563,7 +3563,7 @@ same direction as values, as an optional last value of the stream or future.
 ### 🔀 `canon {stream,future}.cancel-{read,write}`
 
 For canonical definitions:
-```wasm
+```wat
 (canon stream.cancel-read $t $async? (core func $f))
 (canon stream.cancel-write $t $async? (core func $f))
 (canon future.cancel-read $t $async? (core func $f))
@@ -3629,7 +3629,7 @@ caller can assume that ownership of the buffer has been returned.
 ### 🔀 `canon {stream,future}.close-{readable,writable}`
 
 For canonical definitions:
-```wasm
+```wat
 (canon stream.close-readable $t (core func $f))
 (canon future.close-readable $t (core func $f))
 ```
@@ -3637,7 +3637,7 @@ validation specifies:
 * `$f` is given type `(func (param i32))`
 
 and for canonical definitions:
-```wasm
+```wat
 (canon stream.close-writable $t (core func $f))
 (canon future.close-writable $t (core func $f))
 ```
@@ -3681,7 +3681,7 @@ direction as values as an optional last value of the stream or future.
 ### 🔀 `canon error-context.new`
 
 For a canonical definition:
-```wasm
+```wat
 (canon error-context.new $opts (core func $f))
 ```
 validation specifies:
@@ -3720,7 +3720,7 @@ Canonical ABI and stands for an arbitrary host-defined function.)
 ### 🔀 `canon error-context.debug-message`
 
 For a canonical definition:
-```wasm
+```wat
 (canon error-context.debug-message $opts (core func $f))
 ```
 validation specifies:
@@ -3745,7 +3745,7 @@ the pointer and length of the debug string (allocated via `opts.realloc`).
 ### 🔀 `canon error-context.drop`
 
 For a canonical definition:
-```wasm
+```wat
 (canon error-context.drop (core func $f))
 ```
 validation specifies:
@@ -3764,7 +3764,7 @@ async def canon_error_context_drop(task, i):
 ### 🧵 `canon thread.spawn`
 
 For a canonical definition:
-```wasm
+```wat
 (canon thread.spawn (type $ft) (core func $st))
 ```
 validation specifies:
@@ -3811,7 +3811,7 @@ def canon_thread_spawn(f, c):
 ### 🧵 `canon thread.available_parallelism`
 
 For a canonical definition:
-```wasm
+```wat
 (canon thread.available_parallelism (core func $f))
 ```
 validation specifies:
diff --git a/design/mvp/Explainer.md b/design/mvp/Explainer.md
index c7d5c878..479de769 100644
--- a/design/mvp/Explainer.md
+++ b/design/mvp/Explainer.md
@@ -129,7 +129,7 @@ The next kind of definition is, recursively, a component itself. Thus,
 components form trees with all other kinds of definitions only appearing at the
 leaves. For example, with what's defined so far, we can write the following
 component:
-```wasm
+```wat
 (component
   (component
     (core module (func (export "one") (result i32) (i32.const 1)))
@@ -185,7 +185,7 @@ Also [like Core WebAssembly][Core Identifiers], the Component Model text format
 allows *identifiers* to be used in place of these indices, which are resolved
 when parsing into indices in the AST (upon which validation and execution is
 defined). Thus, the following two components are equivalent:
-```wasm
+```wat
 (component
   (core module (; empty ;))
   (component   (; empty ;))
@@ -195,7 +195,7 @@ defined). Thus, the following two components are equivalent:
   (export "M2" (core module 1))
 )
 ```
-```wasm
+```wat
 (component
   (core module $M1 (; empty ;))
   (component $C    (; empty ;))
@@ -251,7 +251,7 @@ indexes into the sort's associated index space to select a definition.
 
 Based on this, we can link two core modules `$A` and `$B` together with the
 following component:
-```wasm
+```wat
 (component
   (core module $A
     (func (export "one") (result i32) (i32.const 1))
@@ -363,12 +363,12 @@ inlinealias ::= (<sort> <u32> <name>+)
 If `<sort>` refers to a `<core:sort>`, then the `<u32>` of `inlinealias` is a
 `<core:instanceidx>`; otherwise it's an `<instanceidx>`. For example, the
 following snippet uses two inline function aliases:
-```wasm
+```wat
 (instance $j (instantiate $J (with "f" (func $i "f"))))
 (export "x" (func $j "g" "h"))
 ```
 which are desugared into:
-```wasm
+```wat
 (alias export $i "f" (func $f_alias))
 (instance $j (instantiate $J (with "f" (func $f_alias))))
 (alias export $j "g" (instance $g_alias))
@@ -379,7 +379,7 @@ which are desugared into:
 For `outer` aliases, the inline sugar is simply the identifier of the outer
 definition, resolved using normal lexical scoping rules. For example, the
 following component:
-```wasm
+```wat
 (component
   (component $C ...)
   (component
@@ -388,7 +388,7 @@ following component:
 )
 ```
 is desugared into:
-```wasm
+```wat
 (component $Parent
   (component $C ...)
   (component
@@ -400,7 +400,7 @@ is desugared into:
 
 Lastly, for symmetry with [imports][func-import-abbrev], aliases can be written
 in an inverted form that puts the sort first:
-```wasm
+```wat
     (func $f (import "i" "f") ...type...) ≡ (import "i" "f" (func $f ...type...))   (WebAssembly 1.0)
           (func $f (alias export $i "f")) ≡ (alias export $i "f" (func $f))
    (core module $m (alias export $i "m")) ≡ (alias export $i "m" (core module $m))
@@ -408,7 +408,7 @@ in an inverted form that puts the sort first:
 ```
 
 With what's defined so far, we're able to link modules with arbitrary renamings:
-```wasm
+```wat
 (component
   (core module $A
     (func (export "one") (result i32) (i32.const 1))
@@ -488,7 +488,7 @@ this, module types start with an empty type index space that is populated by
 `type` declarators, so that, in the future, these `type` declarators can refer to
 type imports local to the module type itself. For example, in the future, the
 following module type would be expressible:
-```wasm
+```wat
 (component $C
   (core type $M (module
     (import "" "T" (type $T))
@@ -511,7 +511,7 @@ future, more kinds of aliases would be meaningful and allowed.
 As an example, the following component defines two semantically-equivalent
 module types, where the former defines the function type via `type` declarator
 and the latter refers via `alias` declarator.
-```wasm
+```wat
 (component $C
   (core type $C1 (module
     (type (func (param i32) (result i32)))
@@ -862,7 +862,7 @@ Relaxing the restrictions of `core:alias` declarators mentioned above, `alias`
 declarators allow both `outer` and `export` aliases of `type` and `instance`
 sorts. This allows the type exports of `instance`-typed import and export
 declarators to be used by subsequent declarators in the type:
-```wasm
+```wat
 (component
   (import "fancy-fs" (instance $fancy-fs
     (export $fs "fs" (instance
@@ -883,7 +883,7 @@ introduced by `importdecl` or `exportdecl`.
 
 With what's defined so far, we can define component types using a mix of type
 definitions:
-```wasm
+```wat
 (component $C
   (type $T (list (tuple string bool)))
   (type $U (option $T))
@@ -927,7 +927,7 @@ nodes. Then, type equality is defined to be AST equality. Importantly, these
 type ASTs do *not* contain any type indices or depend on index space layout;
 these binary format details are consumed by decoding to produce the AST. For
 example, in the following compound component:
-```wasm
+```wat
 (component $A
   (type $ListString1 (list string))
   (type $ListListString1 (list $ListString1))
@@ -990,7 +990,7 @@ subcases of `typebound` to consider: `eq` and `sub`.
 The `eq` bound adds a type equality rule (extending the built-in set of
 subtyping rules mentioned above) saying that the imported type is structurally
 equivalent to the type referenced in the bound. For example, in the component:
-```wasm
+```wat
 (component
   (type $L1 (list u8))
   (import "L2" (type $L2 (eq $L1)))
@@ -1009,7 +1009,7 @@ preceding type definition. Currently (and likely in the MVP), the only
 supported type bound is `resource` (which means "any resource type") and thus
 the only abstract types are abstract *resource* types. As an example, in the
 following component:
-```wasm
+```wat
 (component
   (import "T1" (type $T1 (sub resource)))
   (import "T2" (type $T2 (sub resource)))
@@ -1020,7 +1020,7 @@ the types `$T1` and `$T2` are not equal.
 Once a type is imported, it can be referred to by subsequent equality-bound
 type imports, thereby adding more types that it is equal to. For example, in
 the following component:
-```wasm
+```wat
 (component $C
   (import "T1" (type $T1 (sub resource)))
   (import "T2" (type $T2 (sub resource)))
@@ -1037,7 +1037,7 @@ equal to each other but not to `$List1`.
 Handle types (`own` and `borrow`) are structural types (like `list`) but, since
 they refer to resource types, transitively "inherit" the freshness of abstract
 resource types. For example, in the following component:
-```wasm
+```wat
 (component
   (import "T" (type $T (sub resource)))
   (import "U" (type $U (sub resource)))
@@ -1065,7 +1065,7 @@ each other but not `$Borrow3`. Transitively, the types `$ListOwn1` and
 The above examples all show abstract types in terms of *imports*, but the same
 "freshness" condition applies when aliasing the *exports* of another component
 as well. For example, in this component:
-```wasm
+```wat
 (component
   (import "C" (component $C
     (export "T1" (type (sub resource)))
@@ -1093,7 +1093,7 @@ instantiation generates fresh resource types distinct from all preceding
 instances of the same component, resource types are ["generative"].
 
 For example, in the following example component:
-```wasm
+```wat
 (component
   (type $R1 (resource (rep i32)))
   (type $R2 (resource (rep i32)))
@@ -1107,7 +1107,7 @@ is incompatible with the parameter type of `$f2`.
 The generativity of resource type definitions matches the abstract typing rules
 of type exports mentioned above, which force all clients of the component to
 bind a fresh abstract type. For example, in the following component:
-```wasm
+```wat
 (component
   (component $C
     (type $r1 (export "r1") (resource (rep i32)))
@@ -1127,7 +1127,7 @@ that each instance of `$C` generates two fresh resource types.
 If a single resource type definition is exported more than once, the exports
 after the first are equality-bound to the first export. For example, the
 following component:
-```wasm
+```wat
 (component
   (type $r (resource (rep i32)))
   (export "r1" (type $r))
@@ -1135,7 +1135,7 @@ following component:
 )
 ```
 is assigned the following `componenttype`:
-```wasm
+```wat
 (component
   (export "r1" (type $r1 (sub resource)))
   (export "r2" (type (eq $r1)))
@@ -1149,7 +1149,7 @@ If a component wants to hide this fact and force clients to assume `r1` and
 separate types in the future without breaking clients), an explicit type can be
 ascribed to the export that replaces the `eq` bound with a less-precise `sub`
 bound (using syntax introduced [below](#import-and-export-definitions)).
-```wasm
+```wat
 (component
   (type $r (resource (rep i32)))
   (export "r1" (type $r))
@@ -1157,7 +1157,7 @@ bound (using syntax introduced [below](#import-and-export-definitions)).
 )
 ```
 This component is assigned the following `componenttype`:
-```wasm
+```wat
 (component
   (export "r1" (type (sub resource)))
   (export "r2" (type (sub resource)))
@@ -1170,7 +1170,7 @@ When supplying a resource type (imported *or* defined) to a type import via
 `instantiate`, type checking performs a substitution, replacing all uses of the
 `import` in the instantiated component with the actual type supplied via
 `with`. For example, the following component validates:
-```wasm
+```wat
 (component $P
   (import "C1" (component $C1
     (import "T" (type $T (sub resource)))
@@ -1285,7 +1285,7 @@ validation requires this option to be present (there is no default).
 
 The `(realloc ...)` option specifies a core function that is validated to
 have the following core function type:
-```wasm
+```wat
 (func (param $originalPtr i32)
       (param $originalSize i32)
       (param $alignment i32)
@@ -1314,7 +1314,7 @@ call to a function using these types is highly likely to deadlock).
 🔀 The `(callback ...)` option may only be present in `canon lift` when the
 `async` option has also been set and specifies a core function that is
 validated to have the following core function type:
-```wasm
+```wat
 (func (param $ctx i32)
       (param $event i32)
       (param $payload i32)
@@ -1346,7 +1346,7 @@ stack-switching in component function signatures.
 
 Similar to the `import` and `alias` abbreviations shown above, `canon`
 definitions can also be written in an inverted form that puts the sort first:
-```wasm
+```wat
 (func $f (import "i" "f") ...type...) ≡ (import "i" "f" (func $f ...type...))       (WebAssembly 1.0)
 (func $g ...type... (canon lift ...)) ≡ (canon lift ... (func $g ...type...))
 (core func $h (canon lower ...))      ≡ (canon lower ... (core func $h))
@@ -1356,7 +1356,7 @@ functions (such as types), hence the explicit `sort`.
 
 Using canonical function definitions, we can finally write a non-trivial
 component that takes a string, does some logging, then returns a string.
-```wasm
+```wat
 (component
   (import "logging" (instance $logging
     (export "log" (func (param string)))
@@ -1510,7 +1510,7 @@ hard-coded to always be `i32`.
 
 As an example, the following component imports the `resource.new` built-in,
 allowing it to create and return new resources to its client:
-```wasm
+```wat
 (component
   (import "Libc" (core module $Libc ...))
   (core instance $libc (instantiate $Libc))
@@ -2011,7 +2011,7 @@ of the value definition to be written directly in the text format, analogous to
 avoiding the need to understand type information when encoding or decoding.
 
 For example:
-```wasm
+```wat
 (component
   (value $a bool true)
   (value $b u8  1)
@@ -2085,14 +2085,14 @@ For example:
 
 As with all definition sorts, values may be imported and exported by
 components. As an example value import:
-```wasm
+```wat
 (import "env" (value $env (record (field "locale" (option string)))))
 ```
 As this example suggests, value imports can serve as generalized [environment
 variables], allowing not just `string`, but the full range of `valtype`.
 
 Values can also be exported.  For example:
-```wasm
+```wat
 (component
   (import "system-port" (value $port u16))
   (value $url string "https://example.com")
@@ -2101,7 +2101,7 @@ Values can also be exported.  For example:
 )
 ```
 The inferred type of this component is:
-```wasm
+```wat
 (component
   (import "system-port" (value $port u16))
   (value $url string "https://example.com")
@@ -2132,7 +2132,7 @@ validated to match the signature of `funcidx`.
 
 With this, we can define a component that imports a string and computes a new
 exported string at instantiation time:
-```wasm
+```wat
 (component
   (import "name" (value $name string))
   (import "libc" (core module $Libc
@@ -2345,7 +2345,7 @@ options for naming imports:
   given exported definition.
 
 As an example, the following component uses all 9 cases of imports and exports:
-```wasm
+```wat
 (component
   (import "custom-hook" (func (param string) (result string)))
   (import "wasi:http/handler" (instance
@@ -2387,7 +2387,7 @@ the definition's type, thereby allowing a private (non-exported) type
 definition to be replaced with a public (exported) type definition.
 
 For example, in the following component:
-```wasm
+```wat
 (component
   (import "R1" (type $R1 (sub resource)))
   (type $R2 (resource (rep i32)))
@@ -2411,7 +2411,7 @@ Similar to type exports, value exports may also ascribe a type to keep the preci
 value from becoming part of the type and public interface.
 
 For example:
-```wasm
+```wat
 (component
   (value $url string "https://example.com")
   (export "default-url" (value $url) (value string))
@@ -2419,7 +2419,7 @@ For example:
 ```
 
 The inferred type of this component is:
-```wasm
+```wat
 (component
   (export "default-url" (value string))
 )
@@ -2511,7 +2511,7 @@ the abovementioned functions (again, using the `layer` field to eagerly
 distinguish between modules and components).
 
 For example, the following component:
-```wasm
+```wat
 ;; a.wasm
 (component
   (import "one" (func))
@@ -2528,7 +2528,7 @@ For example, the following component:
 )
 ```
 and module:
-```wasm
+```wat
 ;; b.wasm
 (module
   (import "six" "a" (func))
@@ -2663,7 +2663,7 @@ must be performed recursively.
 Otherwise, function or value imports are treated like an [Imported Default Binding]
 and the Module Record is converted to its default value. This allows the following
 component:
-```wasm
+```wat
 ;; bar.wasm
 (component
   (import "./foo.js" (func (result string)))
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 66c0fd56..3a1f1d0b 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -111,7 +111,7 @@ represents an interface called `host` which provides one function, `log`, which
 takes a single `string` argument. If this were imported into a component then it
 would correspond to:
 
-```wasm
+```wat
 (component
   (import "local:demo/host" (instance $host
     (export "log" (func (param "msg" string)))
@@ -174,7 +174,7 @@ world my-world {
 
 can be thought of as this component type:
 
-```wasm
+```wat
 (type $my-world (component
   (import "host" (instance
     (export "log" (func (param "param" string)))
@@ -616,7 +616,7 @@ world my-world {
 
 would generate this component:
 
-```wasm
+```wat
 (component
   (import "local:demo/shared" (instance $shared
     (type $metadata (record (; ... ;)))
@@ -1746,7 +1746,7 @@ interface namespace {
 }
 ```
 can be packaged into a component as:
-```wasm
+```wat
 (component
   (type (export "types") (component
     (export "local:demo/types" (instance
@@ -1813,7 +1813,7 @@ interface foo {
 }
 ```
 is encoded as:
-```wasm
+```wat
 (component
   (type (export "foo") (component
     (import "wasi:http/types" (instance $types
@@ -1838,7 +1838,7 @@ world the-world {
 }
 ```
 is encoded as:
-```wasm
+```wat
 (component
   (type (export "the-world") (component
     (export "local:demo/the-world" (component
@@ -1868,7 +1868,7 @@ interface console {
 }
 ```
 is encoded as:
-```wasm
+```wat
 (component
   (type (export "the-world") (component
     (export "local:demo/the-world" (component
@@ -1914,7 +1914,7 @@ world proxy {
 }
 ```
 are encoded as:
-```wasm
+```wat
 (component
   (type (export "types") (component
     (export "wasi:http/types" (instance
diff --git a/design/mvp/examples/LinkTimeVirtualization.md b/design/mvp/examples/LinkTimeVirtualization.md
index fbd25b56..1f307e7f 100644
--- a/design/mvp/examples/LinkTimeVirtualization.md
+++ b/design/mvp/examples/LinkTimeVirtualization.md
@@ -14,7 +14,7 @@ instance imported by the `parent` instance.
 
 We start with the `child.wat` that has been written and compiled separately,
 without regard to `parent.wasm`:
-```wasm
+```wat
 ;; child.wat
 (component
   (import "wasi:filesystem/types" (instance
@@ -28,7 +28,7 @@ without regard to `parent.wasm`:
 We want to write a parent component that reuses the child component, giving the
 child component a virtual filesystem. This virtual filesystem can be factored
 out and reused as a separate component:
-```wasm
+```wat
 ;; virtualize.wat
 (component
   (import "wasi:filesystem/types" (instance $fs
@@ -46,7 +46,7 @@ out and reused as a separate component:
 
 We now write the parent component by composing `child.wasm` with
 `virtualize.wasm`:
-```wasm
+```wat
 ;; parent.wat
 (component
   (import "wasi:filesystem/types" (instance $real-fs ...))
@@ -63,7 +63,7 @@ We now write the parent component by composing `child.wasm` with
 Here we import the `child` and `virtualize` components, but they could also be
 trivially copied in-line into the `parent` component using nested component
 definitions in place of imports:
-```wasm
+```wat
 ;; parent.wat
 (component
   (import "wasi:filesystem/types" (instance $real-fs ...))
diff --git a/design/mvp/examples/SharedEverythingDynamicLinking.md b/design/mvp/examples/SharedEverythingDynamicLinking.md
index 914a1de3..bfa19854 100644
--- a/design/mvp/examples/SharedEverythingDynamicLinking.md
+++ b/design/mvp/examples/SharedEverythingDynamicLinking.md
@@ -33,7 +33,7 @@ participating modules. Here, as in most conventions, `libc` serves a special
 role and is assumed to be bundled with the compiler. As part of this special
 role, `libc` defines and exports linear memory, with the convention that
 every other module imports memory from `libc`:
-```wasm
+```wat
 ;; libc.wat
 (module
   (memory (export "memory") 1)
@@ -65,7 +65,7 @@ void* LIBC(malloc)(size_t n);
 
 With these annotations, C programs that include and call this function will be
 compiled to contain the following import:
-```wasm
+```wat
 (import "libc" "malloc" (func (param i32) (result i32)))
 ```
 
@@ -95,7 +95,7 @@ so that client modules generate proper wasm *import definitions* while `libzip.c
 annotates the `zip` definition with an *export* attribute so that this function
 generates a proper *export definition* in the compiled module. Compiling with
 `clang -shared libzip.c` produces a module shaped like:
-```wasm
+```wat
 ;; libzip.wat
 (module
   (import "libc" "memory" (memory 1))
@@ -126,7 +126,7 @@ int main(int argc, char* argv[]) {
 
 When compiled by a (future) component-aware `clang`, the resulting component
 would look like:
-```wasm
+```wat
 ;; zipper.wat
 (component
   (import "libc" (core module $Libc
@@ -207,7 +207,7 @@ Compiling with `clang -shared libimg.c` produces a `libimg` module:
 The main module of the `imgmgk` component is implemented by including
 `stddef.h`, `libzip.h` and `libimg.h`. When compiled by a (future)
 component-aware `clang`, the resulting component would look like:
-```wasm
+```wat
 ;; imgmgk.wat
 (component $Imgmgk
   (import "libc" (core module $Libc ...))
@@ -251,7 +251,7 @@ dynamically-linked modules expressed through `instance` definitions.
 
 Finally, we can create the `app` component by composing the `zipper` and `imgmgk`
 components. The resulting component could look like:
-```wasm
+```wat
 ;; app.wat
 (component
   (import "libc" (core module $Libc ...))

From f8a0fb44cd375cde70cd2e2c9193b308da0aa11b Mon Sep 17 00:00:00 2001
From: Mikhail Katychev <mkatych@gmail.com>
Date: Wed, 29 Jan 2025 15:26:49 -0600
Subject: [PATCH 2/2] typos

---
 design/mvp/Async.md        | 2 +-
 design/mvp/Binary.md       | 4 ++--
 design/mvp/CanonicalABI.md | 6 +++---
 design/mvp/Linking.md      | 2 +-
 design/mvp/WIT.md          | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/design/mvp/Async.md b/design/mvp/Async.md
index 9cf7a16f..5aecfeee 100644
--- a/design/mvp/Async.md
+++ b/design/mvp/Async.md
@@ -644,7 +644,7 @@ this approach is that a non-`shared` component-level function could be safely
 lowered with `async shared`. In the case that the lifted function being lowered
 was also `async shared`, the entire call could happen on the non-main thread
 without a context switch. But if the lifting side was non-`shared`, then the
-Component Model could automatically handle the synchronization of enqueing a
+Component Model could automatically handle the synchronization of enqueuing a
 call to the export (as in the backpressure case mentioned above), returning a
 subtask for the async caller to wait on as usual. Thus, the sync+async
 composition story described above could naturally be extended to a
diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md
index 8026c608..aba39655 100644
--- a/design/mvp/Binary.md
+++ b/design/mvp/Binary.md
@@ -456,7 +456,7 @@ Notes:
     - [`core:utf8`]
 * `&` operator is used to denote bitwise AND operation, which performs AND on every bit of two numbers in their binary form
 * `isnan` is a function, which takes a floating point number as a parameter and returns `true` iff it represents a NaN as defined in [IEEE 754 standard]
-* `||B||` is the length of the byte sequence generated from the production `B` in a derivation as defined in [Core convention auxilary notation]
+* `||B||` is the length of the byte sequence generated from the production `B` in a derivation as defined in [Core convention auxiliary notation]
 
 ## Name Section
 
@@ -518,4 +518,4 @@ named once.
 [module-linking]: https://github.com/WebAssembly/module-linking/blob/main/proposals/module-linking/Explainer.md
 
 [IEEE 754 standard]: https://ieeexplore.ieee.org/document/8766229
-[Core convention auxilary notation]: https://webassembly.github.io/spec/core/binary/conventions.html#auxiliary-notation
+[Core convention auxiliary notation]: https://webassembly.github.io/spec/core/binary/conventions.html#auxiliary-notation
diff --git a/design/mvp/CanonicalABI.md b/design/mvp/CanonicalABI.md
index 5b089e3e..f053fa0f 100644
--- a/design/mvp/CanonicalABI.md
+++ b/design/mvp/CanonicalABI.md
@@ -753,7 +753,7 @@ returned to it when it is notified that the `Subtask` has reached the
 ```
 The maximum flattened core wasm values depends on whether this is a normal
 synchronous call (in which return values are returned by core wasm) or a newer
-async or sychronous-using-`always-task-return` call, in which case return
+async or synchronous-using-`always-task-return` call, in which case return
 values are passed as parameters to `canon task.return`.
 
 Lastly, the `Task.exit` method is called when the task has signalled that it
@@ -887,7 +887,7 @@ A "waitable set" contains a collection of waitables that can be waited on or
 polled for *any* element to make progress. Although the `WaitableSet` class
 below represents `elems` as a `list` and implements `poll` with an O(n) search,
 because a waitable can be associated with at most one set and can contain at
-most one pending event, a real implemenation could instead store a list of
+most one pending event, a real implementation could instead store a list of
 waitables-with-pending-events as a linked list embedded directly in the
 `Waitable` table element to avoid the separate allocation while providing O(1)
 polling.
@@ -2789,7 +2789,7 @@ happens by core wasm calling `waitable-set.wait`.
       task.exit()
       return
 ```
-In contrast, the aynchronous `callback` case does asynchronous waiting in
+In contrast, the asynchronous `callback` case does asynchronous waiting in
 the event loop, with core wasm (repeatedly) returning instructions for what
 to do next:
 ```python
diff --git a/design/mvp/Linking.md b/design/mvp/Linking.md
index 01c060dd..32476a2e 100644
--- a/design/mvp/Linking.md
+++ b/design/mvp/Linking.md
@@ -88,7 +88,7 @@ shared-nothing linking works at the WAT level, see
 With both `wasm-tools link` and `wac`, the developer will have the option to
 either store child modules or components **inline** or to **import** them from
 an external registry. This registry toolchain integration is still in progress,
-but by reusing common support libries such as [`wasm-pkg-tools`], higher-level
+but by reusing common support libraries such as [`wasm-pkg-tools`], higher-level
 tooling can uniformly interact with multiple kinds of storage backends such as
 local directories, [OCI Wasm Artifacts] stored in standard [OCI Registries] and
 [warg registries]. Of note, even when modules or components are stored inline
diff --git a/design/mvp/WIT.md b/design/mvp/WIT.md
index 3a1f1d0b..bc432773 100644
--- a/design/mvp/WIT.md
+++ b/design/mvp/WIT.md
@@ -926,7 +926,7 @@ nested-package-definition ::= package-decl '{' package-items* '}'
 package-items ::= toplevel-use-item | interface-item | world-item
 ```
 
-Essentially, these top level items are [worlds], [interfaces], [use statements][use] and other package defintions.
+Essentially, these top level items are [worlds], [interfaces], [use statements][use] and other package definitions.
 
 ### Feature Gates