tidy: Run tidy style against markdown files.

compiler/rustc_infer/src/infer/lexical_region_resolve/README.md

@@ -1,4 +1,3 @@
-
 Lexical Region Resolution was removed in https://github.com/rust-lang/rust/pull/64790.
 
 Rust now uses Non-lexical lifetimes. For more info, please see the [borrowck

src/doc/rustc/src/exploit-mitigations.md

@@ -378,7 +378,7 @@ C library default allocator<sup id="fnref:5" role="doc-noteref"><a
 href="#fn:5" class="footnote">5</a></sup> since version 1.32.0
 (2019-01-17)[39].
 
-```ignore
+```rust,no_run
 fn main() {
     let mut x = Box::new([0; 1024]);
 

src/doc/rustc/src/lints/levels.md

@@ -62,7 +62,7 @@ warning: unused variable: `x`
 A 'deny' lint produces an error if you violate it. For example, this code
 runs into the `exceeding_bitshifts` lint.
 
-```rust,ignore
+```rust,no_run
 fn main() {
     100u8 << 10;
 }
@@ -232,7 +232,7 @@ pub fn foo() {}
 This is the maximum level for all lints. So for example, if we take our
 code sample from the "deny" lint level above:
 
-```rust,ignore
+```rust,no_run
 fn main() {
     100u8 << 10;
 }

src/doc/rustc/src/lints/listing/index.md

@@ -2,4 +2,4 @@
 
 This section lists out all of the lints, grouped by their default lint levels.
 
-You can also see this list by running `rustc -W help`.
+You can also see this list by running `rustc -W help`.

src/doc/rustc/src/what-is-rustc.md

@@ -39,7 +39,7 @@ $ .\hello.exe # on Windows
 Note that we only ever pass `rustc` the *crate root*, not every file we wish
 to compile. For example, if we had a `main.rs` that looked like this:
 
-```rust,ignore
+```rust,ignore (needs-multiple-files)
 mod foo;
 
 fn main() {
@@ -49,7 +49,7 @@ fn main() {
 
 And a `foo.rs` that had this:
 
-```rust,ignore
+```rust,no_run
 pub fn hello() {
     println!("Hello, world!");
 }

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` -->
+```rust,ignore (platform-specific)
-```ignore
 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!()
 }

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")]

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 
+the crate, provides links to explain technical details, and explains why you
-would want to use the crate.  
+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.
+    /// Use the abstraction function to do this specific thing.
-    pub fn abstract() {}
+    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/

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`:

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;
 

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
+[Rust Reference]: https://doc.rust-lang.org/stable/reference/comments.html#doc-comments

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.

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? 
+`src/lib.rs`. But what about those other arguments?
- - `-o` controls the *o*utput of our docs. Instead of a top-level 
+ - `-o` controls the *o*utput of our docs. Instead of a top-level
- `doc` directory, notice that Cargo puts generated documentation under 
+ `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.

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 
+available to anyone trying to use your crate.  More about tests in the
-upcoming [Documentation tests] chapter.  
+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
+[rustdoc-lints]: lints.md

src/doc/unstable-book/src/compiler-flags/codegen-backend.md

@@ -15,7 +15,7 @@ named `__rustc_codegen_backend` with a signature of `fn() -> Box<dyn rustc_codeg
 See also the [`hotplug_codegen_backend`](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/hotplug_codegen_backend) test
 for a full example.
 
-```rust,ignore
+```rust,ignore (partial-example)
 use rustc_codegen_ssa::traits::CodegenBackend;
 
 struct MyBackend;

src/doc/unstable-book/src/compiler-flags/control-flow-guard.md

@@ -6,7 +6,7 @@ The tracking issue for this feature is: [#68793](https://github.com/rust-lang/ru
 
 The rustc flag `-Z control-flow-guard` enables the Windows [Control Flow Guard](https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard) (CFG) platform security feature.
 
-CFG is an exploit mitigation designed to enforce control-flow integrity for software running on supported [Windows platforms (Windows 8.1 onwards)](https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard). Specifically, CFG uses runtime checks to validate the target address of every indirect call/jump before allowing the call to complete. 
+CFG is an exploit mitigation designed to enforce control-flow integrity for software running on supported [Windows platforms (Windows 8.1 onwards)](https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard). Specifically, CFG uses runtime checks to validate the target address of every indirect call/jump before allowing the call to complete.
 
 During compilation, the compiler identifies all indirect calls/jumps and adds CFG checks. It also emits metadata containing the relative addresses of all address-taken functions. At runtime, if the binary is run on a CFG-aware operating system, the loader uses the CFG metadata to generate a bitmap of the address space and marks those addresses that contain valid targets. On each indirect call, the inserted check determines whether the target address is marked in this bitmap. If the target is not valid, the process is terminated.
 
@@ -35,7 +35,7 @@ The rustc flag `-Z control-flow-guard=nochecks` instructs LLVM to emit the list
 
 ## Control Flow Guard in libraries
 
-It is strongly recommended to also enable CFG checks for all linked libraries, including the standard library. 
+It is strongly recommended to also enable CFG checks for all linked libraries, including the standard library.
 
 To enable CFG in the standard library, use the [cargo `-Z build-std` functionality][build-std] to recompile the standard library with the same configuration options as the main program.
 

src/doc/unstable-book/src/compiler-flags/profile.md

@@ -22,6 +22,6 @@ Once you've built and run your program, files with the `gcno` (after build) and
 You can parse them with [llvm-cov gcov](https://llvm.org/docs/CommandGuide/llvm-cov.html#llvm-cov-gcov) or [grcov](https://github.com/mozilla/grcov).
 
 Please note that `RUSTFLAGS` by default applies to everything that cargo builds and runs during a build!
-When the `--target` flag is explicitly passed to cargo, the `RUSTFLAGS` no longer apply to build scripts and procedural macros. 
+When the `--target` flag is explicitly passed to cargo, the `RUSTFLAGS` no longer apply to build scripts and procedural macros.
-For more fine-grained control consider passing a `RUSTC_WRAPPER` program to cargo that only adds the profiling flags to 
+For more fine-grained control consider passing a `RUSTC_WRAPPER` program to cargo that only adds the profiling flags to
 rustc for the specific crates you want to profile.

src/doc/unstable-book/src/compiler-flags/report-time.md

@@ -34,7 +34,7 @@ Available options:
                 Expected format of environment variable is
                 `VARIABLE=WARN_TIME,CRITICAL_TIME`.
                 Not available for --format=terse
---ensure-time 
+--ensure-time
                 Treat excess of the test execution time limit as
                 error.
                 Threshold values for this option can be configured via

src/doc/unstable-book/src/compiler-flags/tls-model.md

@@ -11,7 +11,7 @@ Supported values for this option are:
 
 - `global-dynamic` - General Dynamic TLS Model (alternatively called Global Dynamic) is the most
 general option usable in all circumstances, even if the TLS data is defined in a shared library
-loaded at runtime and is accessed from code outside of that library.  
+loaded at runtime and is accessed from code outside of that library.
 This is the default for most targets.
 - `local-dynamic` - model usable if the TLS data is only accessed from the shared library or
 executable it is defined in. The TLS data may be in a library loaded after startup (via `dlopen`).

src/doc/unstable-book/src/language-features/auto-traits.md

@@ -1,6 +1,6 @@
 # `auto_traits`
 
-The tracking issue for this feature is [#13231] 
+The tracking issue for this feature is [#13231]
 
 [#13231]: https://github.com/rust-lang/rust/issues/13231
 
@@ -9,15 +9,15 @@ The tracking issue for this feature is [#13231]
 The `auto_traits` feature gate allows you to define auto traits.
 
 Auto traits, like [`Send`] or [`Sync`] in the standard library, are marker traits
-that are automatically implemented for every type, unless the type, or a type it contains, 
+that are automatically implemented for every type, unless the type, or a type it contains,
 has explicitly opted out via a negative impl. (Negative impls are separately controlled
 by the `negative_impls` feature.)
 
 [`Send`]: https://doc.rust-lang.org/std/marker/trait.Send.html
 [`Sync`]: https://doc.rust-lang.org/std/marker/trait.Sync.html
 
-```rust,ignore
+```rust,ignore (partial-example)
-impl !Trait for Type
+impl !Trait for Type {}
 ```
 
 Example:
@@ -40,7 +40,7 @@ fn must_be_valid<T: Valid>(_t: T) { }
 fn main() {
     // works
     must_be_valid( MaybeValid(True) );
-                
+
     // compiler error - trait bound not satisfied
     // must_be_valid( MaybeValid(False) );
 }
@@ -80,7 +80,7 @@ where
 
 Explicit impls may be either positive or negative. They take the form:
 
-```rust,ignore
+```rust,ignore (partial-example)
 impl<...> AutoTrait for StructName<..> { }
 impl<...> !AutoTrait for StructName<..> { }
 ```
@@ -104,4 +104,3 @@ Auto traits cannot have any trait items, such as methods or associated types. Th
 ## Supertraits
 
 Auto traits cannot have supertraits. This is for soundness reasons, as the interaction of coinduction with implied bounds is difficult to reconcile.
-

src/doc/unstable-book/src/language-features/custom-test-frameworks.md

@@ -30,4 +30,3 @@ const WILL_PASS: i32 = 0;
 #[test_case]
 const WILL_FAIL: i32 = 4;
 ```
-

src/doc/unstable-book/src/language-features/infer-static-outlives-requirements.md

@@ -42,4 +42,3 @@ struct Bar<T: 'static> {
     x: T,
 }
 ```
-

src/doc/unstable-book/src/language-features/intrinsics.md

@@ -27,4 +27,3 @@ extern "rust-intrinsic" {
 ```
 
 As with any other FFI functions, these are always `unsafe` to call.
-

src/doc/unstable-book/src/language-features/lang-items.md

@@ -15,8 +15,8 @@ For example, `Box` pointers require two lang items, one for allocation
 and one for deallocation. A freestanding program that uses the `Box`
 sugar for dynamic allocations via `malloc` and `free`:
 
-```rust,ignore
+```rust,ignore (libc-is-finicky)
-#![feature(lang_items, box_syntax, start, libc, core_intrinsics)]
+#![feature(lang_items, box_syntax, start, libc, core_intrinsics, rustc_private)]
 #![no_std]
 use core::intrinsics;
 use core::panic::PanicInfo;
@@ -105,8 +105,8 @@ or overriding the default shim for the C `main` function with your own.
 The function marked `#[start]` is passed the command line parameters
 in the same format as C:
 
-```rust,ignore
+```rust,ignore (libc-is-finicky)
-#![feature(lang_items, core_intrinsics)]
+#![feature(lang_items, core_intrinsics, rustc_private)]
 #![feature(start)]
 #![no_std]
 use core::intrinsics;
@@ -141,8 +141,8 @@ with `#![no_main]` and then create the appropriate symbol with the
 correct ABI and the correct name, which requires overriding the
 compiler's name mangling too:
 
-```rust,ignore
+```rust,ignore (libc-is-finicky)
-#![feature(lang_items, core_intrinsics)]
+#![feature(lang_items, core_intrinsics, rustc_private)]
 #![feature(start)]
 #![no_std]
 #![no_main]

src/doc/unstable-book/src/language-features/non-ascii-idents.md

@@ -19,10 +19,10 @@ const Π: f64 = 3.14f64;
 
 ## Changes to the language reference
 
-> **<sup>Lexer:<sup>**  
+> **<sup>Lexer:<sup>**\
-> IDENTIFIER :  
+> IDENTIFIER :\
-> &nbsp;&nbsp; &nbsp;&nbsp; XID_start XID_continue<sup>\*</sup>  
+> &nbsp;&nbsp; &nbsp;&nbsp; XID_start XID_continue<sup>\*</sup>\
-> &nbsp;&nbsp; | `_` XID_continue<sup>+</sup>  
+> &nbsp;&nbsp; | `_` XID_continue<sup>+</sup>
 
 An identifier is any nonempty Unicode string of the following form:
 

src/doc/unstable-book/src/language-features/or-patterns.md

@@ -11,7 +11,7 @@ a pattern, for example, `Some(A(0) | B(1 | 2))` becomes a valid pattern.
 
 ## Examples
 
-```rust,ignore
+```rust,no_run
 #![feature(or_patterns)]
 
 pub enum Foo {

src/doc/unstable-book/src/language-features/plugin.md

@@ -38,7 +38,7 @@ additional checks for code style, safety, etc. Now let's write a plugin
 [`lint-plugin-test.rs`](https://github.com/rust-lang/rust/blob/master/src/test/ui-fulldeps/auxiliary/lint-plugin-test.rs)
 that warns about any item named `lintme`.
 
-```rust,ignore
+```rust,ignore (requires-stage-2)
 #![feature(plugin_registrar)]
 #![feature(box_syntax, rustc_private)]
 
@@ -77,7 +77,7 @@ pub fn plugin_registrar(reg: &mut Registry) {
 
 Then code like
 
-```rust,ignore
+```rust,ignore (requires-plugin)
 #![feature(plugin)]
 #![plugin(lint_plugin_test)]
 

src/doc/unstable-book/src/language-features/rustc-attrs.md

@@ -18,7 +18,7 @@ Options provided by `#[rustc_layout(...)]` are `debug`, `size`, `align`,
 
 ## Examples
 
-```rust,ignore
+```rust,compile_fail
 #![feature(rustc_attrs)]
 
 #[rustc_layout(abi, size)]

src/doc/unstable-book/src/language-features/unboxed-closures.md

@@ -9,7 +9,7 @@ See Also: [`fn_traits`](../library-features/fn-traits.md)
 ----
 
 The `unboxed_closures` feature allows you to write functions using the `"rust-call"` ABI,
-required for implementing the [`Fn*`] family of traits. `"rust-call"` functions must have 
+required for implementing the [`Fn*`] family of traits. `"rust-call"` functions must have
 exactly one (non self) argument, a tuple representing the argument list.
 
 [`Fn*`]: https://doc.rust-lang.org/std/ops/trait.Fn.html

src/doc/unstable-book/src/language-features/unsized-locals.md

@@ -30,7 +30,7 @@ fn foo(_: dyn Any) {}
 
 The RFC still forbids the following unsized expressions:
 
-```rust,ignore
+```rust,compile_fail
 #![feature(unsized_locals)]
 
 use std::any::Any;
@@ -124,7 +124,7 @@ One of the objectives of this feature is to allow `Box<dyn FnOnce>`.
 
 The RFC also describes an extension to the array literal syntax: `[e; dyn n]`. In the syntax, `n` isn't necessarily a constant expression. The array is dynamically allocated on the stack and has the type of `[T]`, instead of `[T; n]`.
 
-```rust,ignore
+```rust,ignore (not-yet-implemented)
 #![feature(unsized_locals)]
 
 fn mergesort<T: Ord>(a: &mut [T]) {

src/doc/unstable-book/src/language-features/unsized-tuple-coercion.md

@@ -8,7 +8,7 @@ The tracking issue for this feature is: [#42877]
 
 This is a part of [RFC0401]. According to the RFC, there should be an implementation like this:
 
-```rust,ignore
+```rust,ignore (partial-example)
 impl<..., T, U: ?Sized> Unsized<(..., U)> for (..., T) where T: Unsized<U> {}
 ```
 

src/doc/unstable-book/src/library-features/asm.md

@@ -405,7 +405,7 @@ When required, options are specified as the final argument.
 
 The following ABNF specifies the general syntax:
 
-```ignore
+```text
 dir_spec := "in" / "out" / "lateout" / "inout" / "inlateout"
 reg_spec := <register class> / "<explicit register>"
 operand_expr := expr / "_" / expr "=>" expr / expr "=>" "_"

src/doc/unstable-book/src/library-features/concat-idents.md

@@ -19,4 +19,4 @@ fn main() {
     let f = concat_idents!(foo, bar);
     assert_eq!(f(), 23);
 }
-```
+```

src/doc/unstable-book/src/library-features/global-asm.md

@@ -24,15 +24,15 @@ conventions of the assembler in your toolchain.
 
 A simple usage looks like this:
 
-```rust,ignore
+```rust,ignore (requires-external-file)
 # #![feature(global_asm)]
-# you also need relevant target_arch cfgs
+# // you also need relevant target_arch cfgs
 global_asm!(include_str!("something_neato.s"));
 ```
 
 And a more complicated usage looks like this:
 
-```rust,ignore
+```rust,no_run
 # #![feature(global_asm)]
 # #![cfg(any(target_arch = "x86", target_arch = "x86_64"))]
 

src/doc/unstable-book/src/library-features/llvm-asm.md

@@ -10,7 +10,7 @@ For extremely low-level manipulations and performance reasons, one
 might wish to control the CPU directly. Rust supports using inline
 assembly to do this via the `llvm_asm!` macro.
 
-```rust,ignore
+```rust,ignore (pseudo-code)
 llvm_asm!(assembly template
    : output operands
    : input operands

src/doc/unstable-book/src/library-features/test.md

@@ -9,7 +9,7 @@ most widely used part of the `test` crate are benchmark tests, which can test
 the performance of your code.  Let's make our `src/lib.rs` look like this
 (comments elided):
 
-```rust,ignore
+```rust,no_run
 #![feature(test)]
 
 extern crate test;
@@ -83,7 +83,7 @@ the benchmark is no longer benchmarking what one expects. For example, the
 compiler might recognize that some calculation has no external effects and
 remove it entirely.
 
-```rust,ignore
+```rust,no_run
 #![feature(test)]
 
 extern crate test;

src/doc/unstable-book/src/library-features/try-trait.md

@@ -16,7 +16,7 @@ macro on `Poll`, among other things.
 
 Here's an example implementation of the trait:
 
-```rust,ignore
+```rust,ignore (cannot-reimpl-Try)
 /// A distinct type to represent the `None` value of an `Option`.
 ///
 /// This enables using the `?` operator on `Option`; it's rarely useful alone.

src/tools/tidy/src/style.rs

@@ -18,6 +18,8 @@
 
 use std::path::Path;
 
+/// Error code markdown is restricted to 80 columns because they can be
+/// displayed on the console with --example.
 const ERROR_CODE_COLS: usize = 80;
 const COLS: usize = 100;
 
@@ -55,9 +57,9 @@ enum LIUState {
 /// Lines of this form are allowed to be overlength, because Markdown
 /// offers no way to split a line in the middle of a URL, and the lengths
 /// of URLs to external references are beyond our control.
-fn line_is_url(columns: usize, line: &str) -> bool {
+fn line_is_url(is_error_code: bool, columns: usize, line: &str) -> bool {
-    // more basic check for error_codes.rs, to avoid complexity in implementing two state machines
+    // more basic check for markdown, to avoid complexity in implementing two state machines
-    if columns == ERROR_CODE_COLS {
+    if is_error_code {
         return line.starts_with('[') && line.contains("]:") && line.contains("http");
     }
 
@@ -93,8 +95,13 @@ fn line_is_url(columns: usize, line: &str) -> bool {
 /// Returns `true` if `line` is allowed to be longer than the normal limit.
 /// Currently there is only one exception, for long URLs, but more
 /// may be added in the future.
-fn long_line_is_ok(max_columns: usize, line: &str) -> bool {
+fn long_line_is_ok(extension: &str, is_error_code: bool, max_columns: usize, line: &str) -> bool {
-    if line_is_url(max_columns, line) {
+    if extension != "md" || is_error_code {
+        if line_is_url(is_error_code, max_columns, line) {
+            return true;
+        }
+    } else if extension == "md" {
+        // non-error code markdown is allowed to be any length
         return true;
     }
 
@@ -158,8 +165,36 @@ pub fn is_in(full_path: &Path, parent_folder_to_find: &str, folder_to_find: &str
     }
 }
 
+fn skip_markdown_path(path: &Path) -> bool {
+    // These aren't ready for tidy.
+    const SKIP_MD: &[&str] = &[
+        "src/doc/edition-guide",
+        "src/doc/embedded-book",
+        "src/doc/nomicon",
+        "src/doc/reference",
+        "src/doc/rust-by-example",
+        "src/doc/rustc-dev-guide",
+    ];
+    SKIP_MD.iter().any(|p| path.ends_with(p))
+}
+
+fn is_unexplained_ignore(extension: &str, line: &str) -> bool {
+    if !line.ends_with("```ignore") && !line.ends_with("```rust,ignore") {
+        return false;
+    }
+    if extension == "md" && line.trim().starts_with("//") {
+        // Markdown examples may include doc comments with ignore inside a
+        // code block.
+        return false;
+    }
+    true
+}
+
 pub fn check(path: &Path, bad: &mut bool) {
-    super::walk(path, &mut super::filter_dirs, &mut |entry, contents| {
+    fn skip(path: &Path) -> bool {
+        super::filter_dirs(path) || skip_markdown_path(path)
+    }
+    super::walk(path, &mut skip, &mut |entry, contents| {
         let file = entry.path();
         let filename = file.file_name().unwrap().to_string_lossy();
         let extensions = [".rs", ".py", ".js", ".sh", ".c", ".cpp", ".h", ".md", ".css"];
@@ -176,13 +211,6 @@ pub fn check(path: &Path, bad: &mut bool) {
                     a.ends_with("src/doc/book")
             });
 
-        if filename.ends_with(".md")
-            && file.parent().unwrap().file_name().unwrap().to_string_lossy() != "error_codes"
-        {
-            // We don't want to check all ".md" files (almost of of them aren't compliant
-            // currently), just the long error code explanation ones.
-            return;
-        }
         if is_style_file && !is_in(file, "src", "librustdoc") {
             // We only check CSS files in rustdoc.
             return;
@@ -192,11 +220,10 @@ pub fn check(path: &Path, bad: &mut bool) {
             tidy_error!(bad, "{}: empty file", file.display());
         }
 
-        let max_columns = if filename == "error_codes.rs" || filename.ends_with(".md") {
+        let extension = file.extension().unwrap().to_string_lossy();
-            ERROR_CODE_COLS
+        let is_error_code = extension == "md" && is_in(file, "src", "error_codes");
-        } else {
+
-            COLS
+        let max_columns = if is_error_code { ERROR_CODE_COLS } else { COLS };
-        };
 
         let can_contain = contents.contains("// ignore-tidy-")
             || contents.contains("# ignore-tidy-")
@@ -227,7 +254,7 @@ pub fn check(path: &Path, bad: &mut bool) {
             };
             if !under_rustfmt
                 && line.chars().count() > max_columns
-                && !long_line_is_ok(max_columns, line)
+                && !long_line_is_ok(&extension, is_error_code, max_columns, line)
             {
                 suppressible_tidy_err!(
                     err,
@@ -280,7 +307,7 @@ pub fn check(path: &Path, bad: &mut bool) {
                     "copyright notices attributed to the Rust Project Developers are deprecated"
                 );
             }
-            if line.ends_with("```ignore") || line.ends_with("```rust,ignore") {
+            if is_unexplained_ignore(&extension, line) {
                 err(UNEXPLAINED_IGNORE_DOCTEST_INFO);
             }
             if filename.ends_with(".cpp") && line.contains("llvm_unreachable") {