diff --git a/crates/api/c-examples/Makefile b/crates/api/c-examples/Makefile
index d3ef772c46..87c44e06bb 100644
--- a/crates/api/c-examples/Makefile
+++ b/crates/api/c-examples/Makefile
@@ -53,8 +53,8 @@ endif
ifeq (${C_COMP},clang)
CC_COMP = clang++
- LD_GROUP_START =
- LD_GROUP_END =
+ LD_GROUP_START =
+ LD_GROUP_END =
else ifeq (${C_COMP},gcc)
CC_COMP = g++
LD_GROUP_START = -Wl,--start-group
diff --git a/crates/lightbeam/README.md b/crates/lightbeam/README.md
index f3a2b970d1..4fff9400a4 100644
--- a/crates/lightbeam/README.md
+++ b/crates/lightbeam/README.md
@@ -151,7 +151,7 @@ fib:
lea rsp, [rsp + 0x18]
ja .Lloop
.Lreturn:
- ret
+ ret
```
Now obviously I'm not advocating for replacing Firefox's optimising compiler with Lightbeam since the latter can only really produce better code when receiving optimised WebAssembly (and so debug-mode or hand-written WebAssembly may produce much worse output). However, this shows that even with the restrictions of a streaming compiler it's absolutely possible to produce high-quality assembly output. For the assembly above, the Lightbeam output runs within 15% of native speed. This is paramount for one of Lightbeam's intended usecases for real-time systems that want good runtime performance but cannot tolerate compiler bombs.
diff --git a/crates/misc/py/examples/gcd/gcd.rs b/crates/misc/py/examples/gcd/gcd.rs
index fb2acb20b3..2f6ef85b62 100644
--- a/crates/misc/py/examples/gcd/gcd.rs
+++ b/crates/misc/py/examples/gcd/gcd.rs
@@ -1,19 +1,17 @@
-
#[inline(never)]
#[no_mangle]
-pub extern fn gcd(m_: u32, n_: u32) -> u32
-{
- let mut m = m_;
- let mut n = n_;
- while m > 0 {
- let tmp = m;
- m = n % m;
- n = tmp;
- }
- return n;
+pub extern "C" fn gcd(m_: u32, n_: u32) -> u32 {
+ let mut m = m_;
+ let mut n = n_;
+ while m > 0 {
+ let tmp = m;
+ m = n % m;
+ n = tmp;
+ }
+ return n;
}
#[no_mangle]
-pub extern fn test() -> u32 {
- gcd(24, 9)
+pub extern "C" fn test() -> u32 {
+ gcd(24, 9)
}
diff --git a/crates/misc/py/examples/two_modules/one.rs b/crates/misc/py/examples/two_modules/one.rs
index bbd51ec5f4..032b83f822 100644
--- a/crates/misc/py/examples/two_modules/one.rs
+++ b/crates/misc/py/examples/two_modules/one.rs
@@ -1,4 +1,3 @@
-
extern "C" {
fn answer() -> u32;
}
@@ -8,8 +7,8 @@ extern "C" {
static mut PLACE: u32 = 23;
#[no_mangle]
-pub extern fn bar() -> *const u32 {
- unsafe {
+pub extern "C" fn bar() -> *const u32 {
+ unsafe {
PLACE = answer();
// Return a pointer to the exported memory.
(&PLACE) as *const u32
diff --git a/crates/wasi-c/js-polyfill/shell.html b/crates/wasi-c/js-polyfill/shell.html
index f44eda52ca..3b01bda31c 100644
--- a/crates/wasi-c/js-polyfill/shell.html
+++ b/crates/wasi-c/js-polyfill/shell.html
@@ -16,7 +16,7 @@
diff --git a/crates/wasi-common/src/fs/dir_entry.rs b/crates/wasi-common/src/fs/dir_entry.rs
index ff926f1c4c..0c0c34cf80 100644
--- a/crates/wasi-common/src/fs/dir_entry.rs
+++ b/crates/wasi-common/src/fs/dir_entry.rs
@@ -7,7 +7,7 @@ use std::{ffi, io};
///
/// Unlike `std::fs::DirEntry`, this API has no `DirEntry::path`, because
/// absolute paths don't interoperate well with the capability-oriented
-/// security model.
+/// security model.
///
/// TODO: Not yet implemented.
///
diff --git a/docs/embed-rust.md b/docs/embed-rust.md
index a391290b7d..8e52481ab5 100644
--- a/docs/embed-rust.md
+++ b/docs/embed-rust.md
@@ -68,7 +68,7 @@ The instance's exports can be used at this point. This wasm file has only one ex
let answer_fn = instance.exports()[0].func().expect("answer function");
```
-The exported function can be called using the `call` method. Remember that in most of the cases,
+The exported function can be called using the `call` method. Remember that in most of the cases,
a `HostRef<_>` object will be returned, so `borrow()` or `borrow_mut()` method has to be used to refer the
specific object. The exported "answer" function accepts no parameters and returns a single `i32` value.