Format all Markdown files with dprint

This is the result of running `dprint fmt` after making two temporary
changes:

- removing `src/` from the list of excluded directories,
- removing the `rustfmt` configuration.

The effect of the first change is that we normalize the formatting of
all Markdown files. The effect of the second is that we avoid
reformatting code blocks in the Markdown files. I want to reformat
them in a follow-up step since some of the changes seem unnecessary or
undesirable.

Thanks to mdbook-i18n-helpers 0.2, the POT file is nearly unchanged
after this, meaning that all existing translations remain valid. A few
messages were changed because of stray whitespace characters:

     msgid ""
     "Slices always borrow from another object. In this example, `a` has to remain "
    -"'alive' (in scope) for at least as long as our slice. "
    +"'alive' (in scope) for at least as long as our slice."
     msgstr ""

I have not updated CI to require perfectly formatted files. I think
doing so might be annoying since it makes it much harder to submit
small fixes directly from the GitHub editor. So for now, I suggest
that we simply run `dprint` by hand every few weeks. If

  dprint/check#11

is fixed so that `dprint` can annotate the lines that need fixing
directly, then I think we can consider more strict formatting checks.

src/SUMMARY.md

@@ -1,7 +1,9 @@
 # Summary
 
 <!-- Keep first page as index.md to avoid giving it two names. -->
+
 [Welcome to Comprehensive Rust 🦀](index.md)
+
 - [Running the Course](running-the-course.md)
   - [Course Structure](running-the-course/course-structure.md)
   - [Keyboard Shortcuts](running-the-course/keyboard-shortcuts.md)
@@ -11,10 +13,9 @@
   - [Code Samples](cargo/code-samples.md)
   - [Running Cargo Locally](cargo/running-locally.md)
 
-
 # Day 1: Morning
 
-----
+---
 
 - [Welcome](welcome-day-1.md)
   - [What is Rust?](welcome-day-1/what-is-rust.md)
@@ -74,7 +75,7 @@
 
 # Day 2: Morning
 
-----
+---
 
 - [Welcome](welcome-day-2.md)
 
@@ -126,10 +127,9 @@
   - [Iterators and Ownership](exercises/day-2/iterators-and-ownership.md)
   - [Strings and Iterators](exercises/day-2/strings-iterators.md)
 
-
 # Day 3: Morning
 
-----
+---
 
 - [Welcome](welcome-day-3.md)
 - [Generics](generics.md)
@@ -184,10 +184,9 @@
 - [Exercises](exercises/day-3/afternoon.md)
   - [Safe FFI Wrapper](exercises/day-3/safe-ffi-wrapper.md)
 
-
 # Android
 
-----
+---
 
 - [Welcome](android.md)
 - [Setup](android/setup.md)
@@ -210,10 +209,9 @@
   - [With Java](android/interoperability/java.md)
 - [Exercises](exercises/android/morning.md)
 
-
 # Bare Metal: Morning
 
-----
+---
 
 - [Welcome](bare-metal.md)
 - [no_std](bare-metal/no_std.md)
@@ -260,10 +258,9 @@
 - [Exercises](exercises/bare-metal/afternoon.md)
   - [RTC Driver](exercises/bare-metal/rtc.md)
 
-
 # Concurrency: Morning
 
-----
+---
 
 - [Welcome](concurrency.md)
 - [Threads](concurrency/threads.md)
@@ -304,19 +301,17 @@
   - [Dining Philosophers](exercises/concurrency/dining-philosophers-async.md)
   - [Broadcast Chat Application](exercises/concurrency/chat-app.md)
 
-
 # Final Words
 
-----
+---
 
 - [Thanks!](thanks.md)
 - [Other Resources](other-resources.md)
 - [Credits](credits.md)
 
-
 # Solutions
 
-----
+---
 
 - [Solutions](exercises/solutions.md)
   - [Day 1 Morning](exercises/day-1/solutions-morning.md)

src/android/aidl.md

@@ -1,7 +1,9 @@
 # AIDL
 
-The [Android Interface Definition Language
-(AIDL)](https://developer.android.com/guide/components/aidl) is supported in Rust:
+The
+[Android Interface Definition Language
+(AIDL)](https://developer.android.com/guide/components/aidl) is supported in
+Rust:
 
-* Rust code can call existing AIDL servers,
-* You can create new AIDL servers in Rust.
+- Rust code can call existing AIDL servers,
+- You can create new AIDL servers in Rust.

src/android/aidl/client.md

@@ -2,13 +2,13 @@
 
 Finally, we can create a Rust client for our new service.
 
-*birthday_service/src/client.rs*:
+_birthday_service/src/client.rs_:
 
 ```rust,ignore
 {{#include birthday_service/src/client.rs:main}}
 ```
 
-*birthday_service/Android.bp*:
+_birthday_service/Android.bp_:
 
 ```javascript
 {{#include birthday_service/Android.bp:birthday_client}}

src/android/aidl/implementation.md

@@ -2,13 +2,13 @@
 
 We can now implement the AIDL service:
 
-*birthday_service/src/lib.rs*:
+_birthday_service/src/lib.rs_:
 
 ```rust,ignore
 {{#include birthday_service/src/lib.rs:IBirthdayService}}
 ```
 
-*birthday_service/Android.bp*:
+_birthday_service/Android.bp_:
 
 ```javascript
 {{#include birthday_service/Android.bp:libbirthdayservice}}

src/android/aidl/interface.md

@@ -2,13 +2,13 @@
 
 You declare the API of your service using an AIDL interface:
 
-*birthday_service/aidl/com/example/birthdayservice/IBirthdayService.aidl*:
+_birthday_service/aidl/com/example/birthdayservice/IBirthdayService.aidl_:
 
 ```java
 {{#include birthday_service/aidl/com/example/birthdayservice/IBirthdayService.aidl:IBirthdayService}}
 ```
 
-*birthday_service/aidl/Android.bp*:
+_birthday_service/aidl/Android.bp_:
 
 ```javascript
 {{#include birthday_service/aidl/Android.bp}}

src/android/aidl/server.md

@@ -2,13 +2,13 @@
 
 Finally, we can create a server which exposes the service:
 
-*birthday_service/src/server.rs*:
+_birthday_service/src/server.rs_:
 
 ```rust,ignore
 {{#include birthday_service/src/server.rs:main}}
 ```
 
-*birthday_service/Android.bp*:
+_birthday_service/Android.bp_:
 
 ```javascript
 {{#include birthday_service/Android.bp:birthday_server}}

src/android/build-rules.md

@@ -3,7 +3,7 @@
 The Android build system (Soong) supports Rust via a number of modules:
 
 | Module Type       | Description                                                                                        |
-|-------------------|----------------------------------------------------------------------------------------------------|
+| ----------------- | -------------------------------------------------------------------------------------------------- |
 | `rust_binary`     | Produces a Rust binary.                                                                            |
 | `rust_library`    | Produces a Rust library, and provides both `rlib` and `dylib` variants.                            |
 | `rust_ffi`        | Produces a Rust C library usable by `cc` modules, and provides both static and shared variants.    |

src/android/build-rules/library.md

@@ -4,8 +4,8 @@ You use `rust_library` to create a new Rust library for Android.
 
 Here we declare a dependency on two libraries:
 
-* `libgreeting`, which we define below,
-* `libtextwrap`, which is a crate already vendored in
+- `libgreeting`, which we define below,
+- `libtextwrap`, which is a crate already vendored in
   [`external/rust/crates/`][crates].
 
 [crates]: https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/

src/android/interoperability.md

@@ -3,8 +3,8 @@
 Rust has excellent support for interoperability with other languages. This means
 that you can:
 
-* Call Rust functions from other languages.
-* Call functions written in other languages from Rust.
+- Call Rust functions from other languages.
+- Call functions written in other languages from Rust.
 
 When you call functions in a foreign language we say that you're using a
 _foreign function interface_, also known as FFI.

src/android/interoperability/cpp.md

@@ -15,18 +15,19 @@ See the [CXX tutorial][2] for an full example of using this.
 
 - Walk the students through the tutorial step by step.
 
-- Highlight how CXX presents a clean interface without unsafe code in _both languages_.
+- Highlight how CXX presents a clean interface without unsafe code in _both
+  languages_.
 
-- Show the correspondence between [Rust and C++ types](https://cxx.rs/bindings.html):
+- Show the correspondence between
+  [Rust and C++ types](https://cxx.rs/bindings.html):
 
-    - Explain how a Rust `String` cannot map to a C++ `std::string`
-      (the latter does not uphold the UTF-8 invariant). Show that
-      despite being different types, `rust::String` in C++ can be
-      easily constructed from a C++ `std::string`, making it very
-      ergonomic to use.
+  - Explain how a Rust `String` cannot map to a C++ `std::string` (the latter
+    does not uphold the UTF-8 invariant). Show that despite being different
+    types, `rust::String` in C++ can be easily constructed from a C++
+    `std::string`, making it very ergonomic to use.
 
-    - Explain that a Rust function returning `Result<T, E>` becomes a
-      function which throws a `E` exception in C++ (and vice versa).
+  - Explain that a Rust function returning `Result<T, E>` becomes a function
+    which throws a `E` exception in C++ (and vice versa).
 
 </details>
 

src/android/interoperability/java.md

@@ -1,8 +1,9 @@
 # Interoperability with Java
 
-Java can load shared objects via [Java Native Interface
-(JNI)](https://en.wikipedia.org/wiki/Java_Native_Interface). The [`jni`
-crate](https://docs.rs/jni/) allows you to create a compatible library.
+Java can load shared objects via
+[Java Native Interface (JNI)](https://en.wikipedia.org/wiki/Java_Native_Interface).
+The [`jni` crate](https://docs.rs/jni/) allows you to create a compatible
+library.
 
 First, we create a Rust function to export to Java:
 

src/android/interoperability/with-c.md

@@ -17,8 +17,8 @@ fn main() {
 }
 ```
 
-We already saw this in the [Safe FFI Wrapper
-exercise](../../exercises/day-3/safe-ffi-wrapper.md).
+We already saw this in the
+[Safe FFI Wrapper exercise](../../exercises/day-3/safe-ffi-wrapper.md).
 
 > This assumes full knowledge of the target platform. Not recommended for
 > production.

src/android/interoperability/with-c/bindgen/c-library.md

@@ -17,4 +17,3 @@ _interoperability/c/libbirthday/libbirthday.c_:
 ```c
 {{#include c/libbirthday/libbirthday.c}}
 ```
-

src/android/interoperability/with-c/hand-written.md

@@ -14,8 +14,8 @@ fn main() {
 }
 ```
 
-We already saw this in the [Safe FFI Wrapper
-exercise](../../exercises/day-3/safe-ffi-wrapper.md).
+We already saw this in the
+[Safe FFI Wrapper exercise](../../exercises/day-3/safe-ffi-wrapper.md).
 
 > This assumes full knowledge of the target platform. Not recommended for
 > production.

src/android/interoperability/with-c/rust.md

@@ -34,7 +34,6 @@ _interoperability/rust/analyze/Android.bp_
 {{#include rust/analyze/Android.bp}}
 ```
 
-
 Build, push, and run the binary on your device:
 
 ```shell
@@ -43,7 +42,8 @@ Build, push, and run the binary on your device:
 
 <details>
 
-`#[no_mangle]` disables Rust's usual name mangling, so the exported symbol will just be the name of
-the function. You can also use `#[export_name = "some_name"]` to specify whatever name you want.
+`#[no_mangle]` disables Rust's usual name mangling, so the exported symbol will
+just be the name of the function. You can also use
+`#[export_name = "some_name"]` to specify whatever name you want.
 
 </details>

src/android/setup.md

@@ -9,5 +9,6 @@ lunch aosp_cf_x86_64_phone-userdebug
 acloud create
 ```
 
-Please see the [Android Developer
-Codelab](https://source.android.com/docs/setup/start) for details.
+Please see the
+[Android Developer Codelab](https://source.android.com/docs/setup/start) for
+details.

src/async.md

@@ -8,18 +8,18 @@ very low and operating systems provide primitives for efficiently identifying
 I/O that is able to proceed.
 
 Rust's asynchronous operation is based on "futures", which represent work that
-may be completed in the future. Futures are "polled" until they signal that
-they are complete.
+may be completed in the future. Futures are "polled" until they signal that they
+are complete.
 
 Futures are polled by an async runtime, and several different runtimes are
 available.
 
 ## Comparisons
 
- * Python has a similar model in its `asyncio`. However, its `Future` type is
-   callback-based, and not polled. Async Python programs require a "loop",
-   similar to a runtime in Rust.
+- Python has a similar model in its `asyncio`. However, its `Future` type is
+  callback-based, and not polled. Async Python programs require a "loop",
+  similar to a runtime in Rust.
 
- * JavaScript's `Promise` is similar, but again callback-based. The language
-   runtime implements the event loop, so many of the details of Promise
-   resolution are hidden.
+- JavaScript's `Promise` is similar, but again callback-based. The language
+  runtime implements the event loop, so many of the details of Promise
+  resolution are hidden.

src/async/async-await.md

@@ -24,25 +24,25 @@ fn main() {
 
 Key points:
 
-* Note that this is a simplified example to show the syntax. There is no long
+- Note that this is a simplified example to show the syntax. There is no long
   running operation or any real concurrency in it!
 
-* What is the return type of an async call?
-  * Use `let future: () = async_main(10);` in `main` to see the type.
+- What is the return type of an async call?
+  - Use `let future: () = async_main(10);` in `main` to see the type.
 
-* The "async" keyword is syntactic sugar. The compiler replaces the return type
-  with a future. 
+- The "async" keyword is syntactic sugar. The compiler replaces the return type
+  with a future.
 
-* You cannot make `main` async, without additional instructions to the compiler
+- You cannot make `main` async, without additional instructions to the compiler
   on how to use the returned future.
 
-* You need an executor to run async code. `block_on` blocks the current thread
-  until the provided future has run to completion. 
+- You need an executor to run async code. `block_on` blocks the current thread
+  until the provided future has run to completion.
 
-* `.await` asynchronously waits for the completion of another operation. Unlike
+- `.await` asynchronously waits for the completion of another operation. Unlike
   `block_on`, `.await` doesn't block the current thread.
 
-* `.await` can only be used inside an `async` function (or block; these are
-  introduced later). 
+- `.await` can only be used inside an `async` function (or block; these are
+  introduced later).
 
 </details>

src/async/channels.md

@@ -32,18 +32,18 @@ async fn main() {
 
 <details>
 
-* Change the channel size to `3` and see how it affects the execution.
+- Change the channel size to `3` and see how it affects the execution.
 
-* Overall, the interface is similar to the `sync` channels as seen in the
+- Overall, the interface is similar to the `sync` channels as seen in the
   [morning class](concurrency/channels.md).
 
-* Try removing the `std::mem::drop` call. What happens? Why?
+- Try removing the `std::mem::drop` call. What happens? Why?
 
-* The [Flume](https://docs.rs/flume/latest/flume/) crate has channels that
+- The [Flume](https://docs.rs/flume/latest/flume/) crate has channels that
   implement both `sync` and `async` `send` and `recv`. This can be convenient
   for complex applications with both IO and heavy CPU processing tasks.
 
-* What makes working with `async` channels preferable is the ability to combine
+- What makes working with `async` channels preferable is the ability to combine
   them with other `future`s to combine them and create complex control flow.
 
 </details>