tidy: Run tidy style against markdown files.

9 files changed, 83 insertions, 67 deletions

diff --git a/src/doc/rustdoc/src/advanced-features.md b/src/doc/rustdoc/src/advanced-features.md
index 5128ff13b7a..990a6b00d18 100644
--- a/src/doc/rustdoc/src/advanced-features.md
+++ b/src/doc/rustdoc/src/advanced-features.md
@@ -47,8 +47,7 @@ all type errors and name resolution errors with function bodies. Note that this
 work for anything outside a function body: since Rustdoc documents your types, it has to
 know what those types are! For example, this code will work regardless of the platform:
 
-<!-- `ignore` because doc-tests are run with `rustc`, not `rustdoc` -->
-```ignore
+```rust,ignore (platform-specific)
 pub fn f() {
     use std::os::windows::ffi::OsStrExt;
 }
@@ -56,7 +55,7 @@ pub fn f() {
 
 but this will not, because the unknown type is part of the function signature:
 
-```ignore
+```rust,ignore (platform-specific)
 pub fn f() -> std::os::windows::ffi::EncodeWide<'static> {
     unimplemented!()
 }
diff --git a/src/doc/rustdoc/src/documentation-tests.md b/src/doc/rustdoc/src/documentation-tests.md
index 387d86189b0..8e3c6228189 100644
--- a/src/doc/rustdoc/src/documentation-tests.md
+++ b/src/doc/rustdoc/src/documentation-tests.md
@@ -5,12 +5,13 @@ that examples within your documentation are up to date and working.
 
 The basic idea is this:
 
-```ignore
+```rust,no_run
 /// # Examples
 ///
 /// ```
 /// let x = 5;
 /// ```
+# fn f() {}
 ```
 
 The triple backticks start and end code blocks. If this were in a file named `foo.rs`,
@@ -78,12 +79,13 @@ Sometimes, you need some setup code, or other things that would distract
 from your example, but are important to make the tests work. Consider
 an example block that looks like this:
 
-```ignore
+```rust,no_run
 /// ```
 /// /// Some documentation.
 /// # fn foo() {} // this function will be hidden
 /// println!("Hello, World!");
 /// ```
+# fn f() {}
 ```
 
 It will render like this:
@@ -196,12 +198,13 @@ When writing an example, it is rarely useful to include a complete error
 handling, as it would add significant amounts of boilerplate code. Instead, you
 may want the following:
 
-```ignore
+```rust,no_run
 /// ```
 /// use std::io;
 /// let mut input = String::new();
 /// io::stdin().read_line(&mut input)?;
 /// ```
+# fn f() {}
 ```
 
 The problem is that `?` returns a `Result<T, E>` and test functions don't
@@ -210,7 +213,7 @@ return anything, so this will give a mismatched types error.
 You can get around this limitation by manually adding a `main` that returns
 `Result<T, E>`, because `Result<T, E>` implements the `Termination` trait:
 
-```ignore
+```rust,no_run
 /// A doc test using ?
 ///
 /// ```
@@ -222,12 +225,13 @@ You can get around this limitation by manually adding a `main` that returns
 ///     Ok(())
 /// }
 /// ```
+# fn f() {}
 ```
 
 Together with the `# ` from the section above, you arrive at a solution that
 appears to the reader as the initial idea but works with doc tests:
 
-```ignore
+```rust,no_run
 /// ```
 /// use std::io;
 /// # fn main() -> io::Result<()> {
@@ -236,18 +240,20 @@ appears to the reader as the initial idea but works with doc tests:
 /// # Ok(())
 /// # }
 /// ```
+# fn f() {}
 ```
 
 As of version 1.34.0, one can also omit the `fn main()`, but you will have to
 disambiguate the error type:
 
-```ignore
+```rust,no_run
 /// ```
 /// use std::io;
 /// let mut input = String::new();
 /// io::stdin().read_line(&mut input)?;
 /// # Ok::<(), io::Error>(())
 /// ```
+# fn f() {}
 ```
 
 This is an unfortunate consequence of the `?` operator adding an implicit
@@ -417,7 +423,7 @@ Another possible use of `#[cfg(doctest)]` is to test doctests that are included
 without including it in your main documentation. For example, you could write this into your
 `lib.rs` to test your README as part of your doctests:
 
-```rust,ignore
+```rust,no_run
 #![feature(external_doc)]
 
 #[doc(include = "../README.md")]
diff --git a/src/doc/rustdoc/src/how-to-write-documentation.md b/src/doc/rustdoc/src/how-to-write-documentation.md
index 41736e5ee3a..0a7dedb25a1 100644
--- a/src/doc/rustdoc/src/how-to-write-documentation.md
+++ b/src/doc/rustdoc/src/how-to-write-documentation.md
@@ -7,7 +7,7 @@ implementation detail, or leaves readers with unanswered questions.
 
 There are a few tenets to Rust documentation that can help guide anyone through
 the process of documenting libraries so that everyone has an ample opportunity
-to use the code.  
+to use the code.
 
 This chapter covers not only how to write documentation but specifically
 how to write **good** documentation.  It is important to be as clear
@@ -19,31 +19,31 @@ then it should be documented.
 
 Documenting a crate should begin with front-page documentation.  As an
 example, the [`hashbrown`] crate level documentation summarizes the role of
-the crate, provides links to explain technical details, and explains why you 
-would want to use the crate.  
+the crate, provides links to explain technical details, and explains why you
+would want to use the crate.
 
-After introducing the crate, it is important that the front-page gives 
+After introducing the crate, it is important that the front-page gives
 an example of how to use the crate in a real world setting.  Stick to the
 library's role in the example, but do so without shortcuts to benefit users who
-may copy and paste the example to get started. 
+may copy and paste the example to get started.
 
 [`futures`] uses inline comments to explain line by line
-the complexities of using a [`Future`], because a person's first exposure to 
+the complexities of using a [`Future`], because a person's first exposure to
 rust's [`Future`] may be this example.
 
-The [`backtrace`] documentation walks through the whole process, explaining 
+The [`backtrace`] documentation walks through the whole process, explaining
 changes made to the `Cargo.toml` file, passing command line arguments to the
-compiler, and shows a quick example of backtrace in the wild.  
+compiler, and shows a quick example of backtrace in the wild.
 
 Finally, the front-page can eventually become a comprehensive reference
 how to use a crate, like [`regex`].  In this front page, all
-requirements are outlined, the edge cases shown, and practical examples 
+requirements are outlined, the edge cases shown, and practical examples
 provided.  The front page goes on to show how to use regular expressions
 then concludes with crate features.
 
 Don't worry about comparing your crate, which is just beginning, to other more
 developed crates.  To get the documentation to something more polished, start
-incrementally and put in an introduction, example, and features.  Rome was not 
+incrementally and put in an introduction, example, and features.  Rome was not
 built in a day!
 
 The first lines within the `lib.rs` will compose the front-page, and they
@@ -51,7 +51,7 @@ use a different convention than the rest of the rustdocs.  Lines should
 start with `//!` which indicate module-level or crate-level documentation.
 Here's a quick example of the difference:
 
-```rust,ignore
+```rust,no_run
 //! Fast and easy queue abstraction.
 //!
 //! Provides an abstraction over a queue.  When the abstraction is used
@@ -64,13 +64,13 @@ Here's a quick example of the difference:
 /// This module makes it easy.
 pub mod easy {
 
-    /// Use the abstract function to do this specific thing.
-    pub fn abstract() {}
+    /// Use the abstraction function to do this specific thing.
+    pub fn abstraction() {}
 
 }
 ```
 
-Ideally, this first line of documentation is a sentence without highly 
+Ideally, this first line of documentation is a sentence without highly
 technical details, but with a good description of where this crate fits
 within the rust ecosystem.  Users should know whether this crate meets their use
 case after reading this line.
@@ -95,7 +95,7 @@ It is recommended that each item's documentation follows this basic structure:
 
 This basic structure should be straightforward to follow when writing your
 documentation; while you might think that a code example is trivial,
-the examples are really important because they can help users understand 
+the examples are really important because they can help users understand
 what an item is, how it is used, and for what purpose it exists.
 
 Let's see an example coming from the [standard library] by taking a look at the
@@ -133,7 +133,7 @@ for argument in env::args() {
 [`args_os`]: ./fn.args_os.html
 ``````
 
-Everything before the first empty line will be reused to describe the component 
+Everything before the first empty line will be reused to describe the component
 in searches and module overviews.  For example, the function `std::env::args()`
 above will be shown on the [`std::env`] module documentation.  It is good
 practice to keep the summary to one line: concise writing is a goal of good
@@ -225,7 +225,7 @@ details on the exact syntax supported.
 [commonmark markdown specification]: https://commonmark.org/
 [commonmark quick reference]: https://commonmark.org/help/
 [env::args]: https://doc.rust-lang.org/stable/std/env/fn.args.html
-[`Future`]: https://doc.rust-lang.org/std/future/trait.Future.html 
+[`Future`]: https://doc.rust-lang.org/std/future/trait.Future.html
 [`futures`]: https://docs.rs/futures/0.3.5/futures/
 [`hashbrown`]: https://docs.rs/hashbrown/0.8.2/hashbrown/
 [`regex`]: https://docs.rs/regex/1.3.9/regex/
diff --git a/src/doc/rustdoc/src/lints.md b/src/doc/rustdoc/src/lints.md
index 41292b3d838..cce3623dc8f 100644
--- a/src/doc/rustdoc/src/lints.md
+++ b/src/doc/rustdoc/src/lints.md
@@ -3,10 +3,11 @@
 `rustdoc` provides lints to help you writing and testing your documentation. You
 can use them like any other lints by doing this:
 
-```rust,ignore
+```rust
 #![allow(missing_docs)] // allows the lint, no diagnostics will be reported
 #![warn(missing_docs)] // warn if there are missing docs
 #![deny(missing_docs)] // error if there are missing docs
+# //! Crate docs.
 ```
 
 Here is the list of the lints provided by `rustdoc`:
diff --git a/src/doc/rustdoc/src/passes.md b/src/doc/rustdoc/src/passes.md
index 081e477de80..140b832f19a 100644
--- a/src/doc/rustdoc/src/passes.md
+++ b/src/doc/rustdoc/src/passes.md
@@ -32,8 +32,9 @@ Without this pass, these items will remain in the output.
 
 When you write a doc comment like this:
 
-```rust,ignore
+```rust,no_run
 /// This is a documentation comment.
+# fn f() {}
 ```
 
 There's a space between the `///` and that `T`. That spacing isn't intended
@@ -52,9 +53,10 @@ documentation string.
 
 For example:
 
-```rust,ignore
+```rust,no_run
 #[doc = "This is the first line."]
 #[doc = "This is the second line."]
+# fn f() {}
 ```
 
 Gets collapsed into a single doc string of
@@ -68,7 +70,7 @@ This is the second line.
 
 This removes documentation for any non-public items, so for example:
 
-```rust,ignore
+```rust,no_run
 /// These are private docs.
 struct Private;
 
diff --git a/src/doc/rustdoc/src/references.md b/src/doc/rustdoc/src/references.md
index 1e050e321d2..b0e2437392c 100644
--- a/src/doc/rustdoc/src/references.md
+++ b/src/doc/rustdoc/src/references.md
@@ -3,7 +3,7 @@
 There are many great `rustdoc` references out there.
 If you know of other great resources, please submit a pull request!
 
-## Official 
+## Official
 
 - [Learn Rust]
 - [Rust By Example]
@@ -11,7 +11,7 @@ If you know of other great resources, please submit a pull request!
 - [RFC 1574: More API Documentation Conventions]
 - [RFC 1946: Intra Rustdoc Links]
 
-## Community 
+## Community
 - [API Guidelines]
 - [Github tagged RFCs]
 - [Github tagged issues]
@@ -28,4 +28,4 @@ If you know of other great resources, please submit a pull request!
 [RFC 1946: Intra Rustdoc Links]: https://rust-lang.github.io/rfcs/1946-intra-rustdoc-links.html
 [RFC (stalled) front page styleguide]: https://github.com/rust-lang/rfcs/pull/1687
 [Rust By Example]: https://doc.rust-lang.org/stable/rust-by-example/meta/doc.html
-[Rust Reference]: https://doc.rust-lang.org/stable/reference/comments.html#doc-comments
\ No newline at end of file
+[Rust Reference]: https://doc.rust-lang.org/stable/reference/comments.html#doc-comments
diff --git a/src/doc/rustdoc/src/the-doc-attribute.md b/src/doc/rustdoc/src/the-doc-attribute.md
index ef143c8727e..52f2a3728fa 100644
--- a/src/doc/rustdoc/src/the-doc-attribute.md
+++ b/src/doc/rustdoc/src/the-doc-attribute.md
@@ -7,9 +7,10 @@ The most basic function of `#[doc]` is to handle the actual documentation
 text. That is, `///` is syntax sugar for `#[doc]`. This means that these two
 are the same:
 
-```rust,ignore
+```rust,no_run
 /// This is a doc comment.
 #[doc = " This is a doc comment."]
+# fn f() {}
 ```
 
 (Note the leading space in the attribute version.)
@@ -18,16 +19,18 @@ In most cases, `///` is easier to use than `#[doc]`. One case where the latter i
 when generating documentation in macros; the `collapse-docs` pass will combine multiple
 `#[doc]` attributes into a single doc comment, letting you generate code like this:
 
-```rust,ignore
+```rust,no_run
 #[doc = "This is"]
 #[doc = " a "]
 #[doc = "doc comment"]
+# fn f() {}
 ```
 
 Which can feel more flexible. Note that this would generate this:
 
-```rust,ignore
+```rust,no_run
 #[doc = "This is\n a \ndoc comment"]
+# fn f() {}
 ```
 
 but given that docs are rendered via Markdown, it will remove these newlines.
@@ -45,7 +48,7 @@ These options control how the docs look at a crate level.
 
 This form of the `doc` attribute lets you control the favicon of your docs.
 
-```rust,ignore
+```rust,no_run
 #![doc(html_favicon_url = "https://example.com/favicon.ico")]
 ```
 
@@ -59,7 +62,7 @@ If you don't use this attribute, there will be no favicon.
 This form of the `doc` attribute lets you control the logo in the upper
 left hand side of the docs.
 
-```rust,ignore
+```rust,no_run
 #![doc(html_logo_url = "https://example.com/logo.jpg")]
 ```
 
@@ -73,7 +76,7 @@ If you don't use this attribute, there will be no logo.
 This form of the `doc` attribute lets you control where the "run" buttons
 on your documentation examples make requests to.
 
-```rust,ignore
+```rust,no_run
 #![doc(html_playground_url = "https://playground.example.com/")]
 ```
 
@@ -88,7 +91,7 @@ When a feature is unstable, an issue number for tracking the feature must be
 given. `rustdoc` uses this number, plus the base URL given here, to link to
 the tracking issue.
 
-```rust,ignore
+```rust,no_run
 #![doc(issue_tracker_base_url = "https://github.com/rust-lang/rust/issues/")]
 ```
 
@@ -103,7 +106,7 @@ available. If that is not available, then it will use the `html_root_url`
 value in the extern crate if it is available. If that is not available, then
 the extern items will not be linked.
 
-```rust,ignore
+```rust,no_run
 #![doc(html_root_url = "https://docs.rs/serde/1.0")]
 ```
 
@@ -112,7 +115,7 @@ the extern items will not be linked.
 By default, `rustdoc` will include the source code of your program, with links
 to it in the docs. But if you include this:
 
-```rust,ignore
+```rust,no_run
 #![doc(html_no_source)]
 ```
 
@@ -123,7 +126,7 @@ it will not.
 By default, `rustdoc` will automatically add a line with `extern crate my_crate;` into each doctest.
 But if you include this:
 
-```rust,ignore
+```rust,no_run
 #![doc(test(no_crate_inject))]
 ```
 
@@ -134,7 +137,7 @@ it will not.
 This form of the `doc` attribute allows you to add arbitrary attributes to all your doctests. For
 example, if you want your doctests to fail if they produce any warnings, you could add this:
 
-```rust,ignore
+```rust,no_run
 #![doc(test(attr(deny(warnings))))]
 ```
 
@@ -148,7 +151,7 @@ they are documented.
 These attributes are used on `use` statements, and control where the documentation shows
 up. For example, consider this Rust code:
 
-```rust,ignore
+```rust,no_run
 pub use bar::Bar;
 
 /// bar docs
@@ -156,6 +159,7 @@ pub mod bar {
     /// the docs for Bar
     pub struct Bar;
 }
+# fn main() {}
 ```
 
 The documentation will generate a "Re-exports" section, and say `pub use bar::Bar;`, where
@@ -163,9 +167,11 @@ The documentation will generate a "Re-exports" section, and say `pub use bar::Ba
 
 If we change the `use` line like this:
 
-```rust,ignore
+```rust,no_run
 #[doc(inline)]
 pub use bar::Bar;
+# pub mod bar { pub struct Bar; }
+# fn main() {}
 ```
 
 Instead, `Bar` will appear in a `Structs` section, just like `Bar` was defined at the
@@ -173,7 +179,7 @@ top level, rather than `pub use`'d.
 
 Let's change our original example, by making `bar` private:
 
-```rust,ignore
+```rust,no_run
 pub use bar::Bar;
 
 /// bar docs
@@ -181,6 +187,7 @@ mod bar {
     /// the docs for Bar
     pub struct Bar;
 }
+# fn main() {}
 ```
 
 Here, because `bar` is not public, `Bar` wouldn't have its own page, so there's nowhere
@@ -188,7 +195,7 @@ to link to. `rustdoc` will inline these definitions, and so we end up in the sam
 as the `#[doc(inline)]` above; `Bar` is in a `Structs` section, as if it were defined at
 the top level. If we add the `no_inline` form of the attribute:
 
-```rust,ignore
+```rust,no_run
 #[doc(no_inline)]
 pub use bar::Bar;
 
@@ -197,6 +204,7 @@ mod bar {
     /// the docs for Bar
     pub struct Bar;
 }
+# fn main() {}
 ```
 
 Now we'll have a `Re-exports` line, and `Bar` will not link to anywhere.
diff --git a/src/doc/rustdoc/src/what-is-rustdoc.md b/src/doc/rustdoc/src/what-is-rustdoc.md
index 32dc1e02bb3..7a444d77c09 100644
--- a/src/doc/rustdoc/src/what-is-rustdoc.md
+++ b/src/doc/rustdoc/src/what-is-rustdoc.md
@@ -32,7 +32,7 @@ $ rustdoc src/lib.rs
 This will create a new directory, `doc`, with a website inside! In our case,
 the main page is located in `doc/lib/index.html`. If you open that up in
 a web browser, you will see a page with a search bar, and "Crate lib" at the
-top, with no contents. 
+top, with no contents.
 
 ## Configuring rustdoc
 
@@ -89,18 +89,18 @@ dependency=<path>/docs/target/debug/deps
 You can see this with `cargo doc --verbose`.
 
 It generates the correct `--crate-name` for us, as well as pointing to
-`src/lib.rs`. But what about those other arguments? 
- - `-o` controls the *o*utput of our docs. Instead of a top-level 
- `doc` directory, notice that Cargo puts generated documentation under 
+`src/lib.rs`. But what about those other arguments?
+ - `-o` controls the *o*utput of our docs. Instead of a top-level
+ `doc` directory, notice that Cargo puts generated documentation under
  `target`. That is the idiomatic place for generated files in Cargo projects.
- - `-L` flag helps rustdoc find the dependencies your code relies on. 
+ - `-L` flag helps rustdoc find the dependencies your code relies on.
  If our project used dependencies, we would get documentation for them as well!
 
 ## Outer and inner documentation
 
 The `///` syntax is used to document the item present after it.
 That's why it is called an outer documentation.
-There is another syntax: `//!`, which is used to document the 
+There is another syntax: `//!`, which is used to document the
 item it is present inside. It is called an inner documentation.
 It is often used when documenting the entire crate,
 because nothing comes before it: it is the root of the crate.
diff --git a/src/doc/rustdoc/src/what-to-include.md b/src/doc/rustdoc/src/what-to-include.md
index 878c75baae7..9683f519be1 100644
--- a/src/doc/rustdoc/src/what-to-include.md
+++ b/src/doc/rustdoc/src/what-to-include.md
@@ -38,10 +38,10 @@ warning: 1 warning emitted
 
 As a library author, adding the lint `#![deny(missing_docs)]` is a great way to
 ensure the project does not drift away from being documented well, and
-`#![warn(missing_docs)]` is a good way to move towards comprehensive 
+`#![warn(missing_docs)]` is a good way to move towards comprehensive
 documentation.  In addition to docs, `#![deny(missing_doc_code_examples)]`
 ensures each function contains a usage example.  In our example above, the
-warning is resolved by adding crate level documentation. 
+warning is resolved by adding crate level documentation.
 
 There are more lints in the upcoming chapter [Lints][rustdoc-lints].
 
@@ -58,7 +58,7 @@ users to figure out how to put the `async` code into their own runtime.
 
 It is preferred that `unwrap()` not be used inside an example, and some of the
 error handling components be hidden if they make the example too difficult to
-follow.  
+follow.
 
 ``````text
 /// Example
@@ -66,9 +66,9 @@ follow.
 /// let fourtytwo = "42".parse::<u32>()?;
 /// println!("{} + 10 = {}", fourtytwo, fourtytwo+10);
 /// ```
-``````  
+``````
 
-When rustdoc wraps that in a main function, it will fail to compile because the 
+When rustdoc wraps that in a main function, it will fail to compile because the
 `ParseIntError` trait is not implemented.  In order to help both your audience
 and your test suite, this example needs some additional code:
 
@@ -81,17 +81,17 @@ and your test suite, this example needs some additional code:
 /// #     Ok(())
 /// # }
 /// ```
-``````  
+``````
 
 The example is the same on the doc page, but has that extra information
-available to anyone trying to use your crate.  More about tests in the 
-upcoming [Documentation tests] chapter.  
+available to anyone trying to use your crate.  More about tests in the
+upcoming [Documentation tests] chapter.
 
 ## What to Exclude
 
 Certain parts of your public interface may be included by default in the output
 of rustdoc.  The attribute `#[doc(hidden)]` can hide implementation details
-to encourage idiomatic use of the crate.  
+to encourage idiomatic use of the crate.
 
 For example, an internal `macro!` that makes the crate easier to implement can
 become a footgun for users when it appears in the public documentation.  An
@@ -101,11 +101,11 @@ detailed in the [API Guidelines].
 ## Customizing the output
 
 It is possible to pass a custom css file to `rustdoc` and style the
-documentation.  
+documentation.
 
 ```bash
 rustdoc --extend-css custom.css src/lib.rs
-``` 
+```
 
 A good example of using this feature to create a dark theme is documented [on
 this blog].  Just remember, dark theme is already included in the rustdoc output
@@ -122,4 +122,4 @@ Here is an example of a new theme, [Ayu].
 [API Guidelines]: https://rust-lang.github.io/api-guidelines/documentation.html#rustdoc-does-not-show-unhelpful-implementation-details-c-hidden
 [Documentation tests]: documentation-tests.md
 [on this blog]: https://blog.guillaume-gomez.fr/articles/2016-09-16+Generating+doc+with+rustdoc+and+a+custom+theme
-[rustdoc-lints]: lints.md
\ No newline at end of file
+[rustdoc-lints]: lints.md