rustfmt and trim trailing whitespace.

crates/api/c-examples/Makefile

@@ -53,8 +53,8 @@ endif
 
 ifeq (${C_COMP},clang)
   CC_COMP = clang++
-  LD_GROUP_START = 
+  LD_GROUP_START =
-  LD_GROUP_END = 
+  LD_GROUP_END =
 else ifeq (${C_COMP},gcc)
   CC_COMP = g++
   LD_GROUP_START = -Wl,--start-group

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.

crates/misc/py/examples/gcd/gcd.rs

@@ -1,19 +1,17 @@
-
 #[inline(never)]
 #[no_mangle]
-pub extern fn gcd(m_: u32, n_: u32) -> u32
+pub extern "C" fn gcd(m_: u32, n_: u32) -> u32 {
-{
+    let mut m = m_;
-        let mut m = m_;
+    let mut n = n_;
-        let mut n = n_;
+    while m > 0 {
-        while m > 0 {
+        let tmp = m;
-                let tmp = m;
+        m = n % m;
-                m = n % m;
+        n = tmp;
-                n = tmp;
+    }
-        }       
+    return n;
-        return n;
 }
 
 #[no_mangle]
-pub extern fn test() -> u32 {
+pub extern "C" fn test() -> u32 {
-  gcd(24, 9)
+    gcd(24, 9)
 }

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 {
+pub extern "C" fn bar() -> *const u32 {
-    unsafe { 
+    unsafe {
         PLACE = answer();
         // Return a pointer to the exported memory.
         (&PLACE) as *const u32

crates/wasi-c/js-polyfill/shell.html

@@ -16,7 +16,7 @@
     <figure style="overflow:visible;" id="spinner"><div class="spinner"></div><center style="margin-top:0.5em"><strong>WASI</strong></center></figure>
     <div class="wasi" id="status">Downloading...</div>
     <div class="wasi">
-      <progress value="0" max="100" id="progress" hidden=1></progress>  
+      <progress value="0" max="100" id="progress" hidden=1></progress>
     </div>
     <img class="wasi" src="WASI-small.png" width="200" height="200" border="0" alt="WASI logo">
     <input class="wasi" type="file" id="input" onchange="_handleFiles(this.files)">

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.
 ///

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.