fix: typos in documentation files (#10227)

* Update README.md

* Update compiler.rs

* Update types.rs

* Update pulley.rs

* Update func.rs

crates/cranelift/src/compiler.rs

@@ -124,7 +124,7 @@ impl Compiler {
         }
     }
 
-    /// Peform an indirect call from Cranelift-generated code to native code in
+    /// Perform an indirect call from Cranelift-generated code to native code in
     /// Wasmtime itself.
     ///
     /// For native platforms this is a simple `call_indirect` instruction but

crates/environ/src/types.rs

@@ -229,7 +229,7 @@ impl WasmValType {
         match bits {
             32 => Self::I32,
             64 => Self::I64,
-            size => panic!("invaid int bits for WasmValType: {size}"),
+            size => panic!("invalid int bits for WasmValType: {size}"),
         }
     }
 }

crates/wasi-preview1-component-adapter/provider/README.md

@@ -61,7 +61,7 @@ To robustly support rich types, composition, and easier interoperability, the [C
 
 To standardize underlying system interoperability (ex. reading files, system time) in code compiled to WebAssembly, the [WebAssembly System Interface ("WASI")][wasi] was created. WASI is implemented by language tool chains (ex. Rust supports `wasm32-wasi`/`wasm32-wasip1` as a target, with [support for `wasm32-wasip2` on the way][rust-target-wasm32-wasi]), and enables compiling a WebAssembly component that utilizes [the interfaces that make up WASI Preview1][wasi-p1-interfaces].
 
-In the ongoing work of building WASI, WASI Preview2 which contains more functionality [has been released][wasi-p2-release] -- but building directly to Preview2 is not yet integrated into language toolchains. However, Preview1 components (which *can* be produced by curren toolchains) can be *adapted* to WASI Preview2.
+In the ongoing work of building WASI, WASI Preview2 which contains more functionality [has been released][wasi-p2-release] -- but building directly to Preview2 is not yet integrated into language toolchains. However, Preview1 components (which *can* be produced by current toolchains) can be *adapted* to WASI Preview2.
 
 This is where component adapters come in.
 

crates/wasmtime/src/profiling_agent/pulley.rs

@@ -9,7 +9,7 @@
 //! Pulley being executed in-process and serializing it to a file.
 //!
 //! The file collected here is populated by a sampling thread in-process. This
-//! sampling thread only collects the current program counter of any interpeters
+//! sampling thread only collects the current program counter of any interpreters
 //! in the process. This does not collect stack traces at all. That means that
 //! this profiler is only suitable for looking at "self time" and is not
 //! suitable for getting a broader picture of what's going on (e.g. why
@@ -157,7 +157,7 @@ impl ProfilingAgent for PulleyAgent {
 ///
 /// * Needs to sample, at `state.sampling_freq`, the state of all known
 ///   interpreters. Ideally this sampling is as steady as possible.
-/// * Needs to clean up interpeters which have been destroyed as there's
+/// * Needs to clean up interpreters which have been destroyed as there's
 ///   otherwise no hook for doing so.
 /// * Needs to send batches of samples to the recording thread to get written to
 ///   the filesystem.

crates/wasmtime/src/runtime/func.rs

@@ -1648,7 +1648,7 @@ fn enter_wasm<T>(store: &mut StoreContextMut<'_, T>) -> Option<usize> {
     // When Cranelift has support for the host then we might be running native
     // compiled code meaning we need to read the actual stack pointer. If
     // Cranelift can't be used though then we're guaranteed to be running pulley
-    // in which case this stack poitner isn't actually used as Pulley has custom
+    // in which case this stack pointer isn't actually used as Pulley has custom
     // mechanisms for stack overflow.
     #[cfg(has_host_compiler_backend)]
     let stack_pointer = crate::runtime::vm::get_stack_pointer();