Apply several markup fixes

text/0048-traits.md

@@ -26,7 +26,7 @@ put onto a surer footing.
 
 ## Use cases
 
-### Poor interaction with overloadable deref and index <a name=overload>
+### Poor interaction with overloadable deref and index { #overload }
 
 *Addressed by:* New method resolution algorithm.
 
@@ -66,7 +66,7 @@ manually specified by making the receiver type fully explicit: `(&mut
 address this problem, as well as the question of how to handle copies
 and moves of the referent (use #3 in my list above).
 
-### Lack of backtracking <a name=backtrack>
+### Lack of backtracking { #backtrack }
 
 *Addressed by:* New method resolution algorithm.
 
@@ -190,7 +190,7 @@ property.  And the popularity and usefulness of blanket impls cannot
 be denied.  Therefore, I think this property ("always being able to
 add impls") is not especially useful or important.
 
-### Hokey implementation <a name=hokey>
+### Hokey implementation { #hokey }
 
 *Addressed by:* Gradual vtable resolution algorithm
 
@@ -298,7 +298,7 @@ personal preference, if we can achieve it).
 The coherence rules fall into two categories: the *orphan* restriction
 and the *overlapping implementations* restriction.
 
-<a name=orphan>
+<span id="orphan"></span>
 
 *Orphan check*: Every implementation must meet one of
 the following conditions:
@@ -679,9 +679,9 @@ probably an error. DEFERRED obligations are ok until we reach the end
 of the function. For details, please refer to the
 [prototype][prototype].
 
-# Alternatives and downsides <a name=alternatives>
+# Alternatives and downsides { #alternatives }
 
-## Autoderef and ambiguity <a name=ambig>
+## Autoderef and ambiguity { #ambig }
 
 The addition of a `Deref` trait makes autoderef complicated, because
 we may encounter situations where the smart pointer *and* its
@@ -707,46 +707,46 @@ needs to be evaluated.
 
 # Footnotes
 
-<a name=1>
+<span id="1"></span>
 
 **Note 1:** when combining with DST, the `in` keyword goes
 first, and then any other qualifiers. For example, `in unsized RHS` or
 `in type RHS` etc. (The precise qualifier in use will depend on the
 DST proposal.)
 
-<a name=2>
+<span id="2"></span>
 
 **Note 2:** Note that the `DerefMut<T>` trait extends
 `Deref<T>`, so if a type supports mutable derefs, it must also support
 immutable derefs.
 
-<a name=3>
+<span id="3"></span>
 
 **Note 3:** The restriction that inputs must precede outputs
 is not strictly necessary. I added it to keep options open concerning
 associated types and so forth. See the
 [Alternatives section](#alternatives), specifically the section on
 [associated types](#assoc).
 
-<a name=4>
+<span id="4"></span>
 
 **Note 4:** The prioritization of inherent methods could be
 reconsidered after DST has been implemented. It is currently needed to
 make impls like `impl Trait for ~Trait` work.
 
-<a name=5>
+<span id="5"></span>
 
 **Note 5:** The set of in-scope traits is currently defined
 as those that are imported by name. PR #37 proposes possible changes
 to this rule.
 
-<a name=6>
+<span id="6"></span>
 
 **Note 6:** In the section on [autoderef and ambiguity](#ambig), I
 discuss alternate rules that might allow us to lift the requirement
 that the receiver be named `self`.
 
-<a name=7>
+<span id="7"></span>
 
 **Note 7:** I am considering introducing mechanisms in a subsequent
 RFC that could be used to express mutual exclusion of traits.

text/0116-no-module-shadowing.md

@@ -181,11 +181,11 @@ released.
 
   Right now its legal to write this:
   ```rust
-fn main() {
+  fn main() {
         use Bar = std::result::Result;
         use Bar = std::option::Option;
         let x: Bar<uint> = None;
-}
+  }
   ```
   where the latter `use` shadows the former. This would have to be forbidden as well,
   however the current semantic seems like a accident anyway.

text/0256-remove-refcounting-gc-of-t.md

@@ -47,7 +47,7 @@ still in place; the move to a library type `Gc<T>` was just a shift in
 perspective from the end-user's point of view (and that of the
 parser).
 
-## Recent history: Removing uses of Gc<T> from the compiler
+## Recent history: Removing uses of `Gc<T>` from the compiler
 
 Largely due to the tireless efforts of `eddyb`, one of the primary
 clients of `Gc<T>`, namely the `rustc` compiler itself, has little to

text/0736-privacy-respecting-fru.md

@@ -309,7 +309,7 @@ Here is an attempt to transcribe/summarize them:
 
      This seems pretty fragile; i.e., easy to forget.
 
-  6. Outlaw the trivial FRU form Foo { ..<expr> }. That is, to use
+  6. Outlaw the trivial FRU form `Foo { ..<expr> }`. That is, to use
      FRU, you have to use at least one field in the constructing
      expression. Again, this implies that types like Vec and HashMap
      will not be subject to the vulnerability outlined here.

text/0738-variance.md

@@ -348,8 +348,7 @@ contravariant.
 **Why contravariance?** To see why contravariance is correct, you have
 to consider what it means for `Self` to be contravariant for a marker
 trait. It means that if I have evidence that `T : Copy`, then I can
-use that as evidence to show that `U
-: Copy` if `U <: T`. More formally:
+use that as evidence to show that `U : Copy` if `U <: T`. More formally:
 
     (T : Copy) <: (U : Copy)   // I can use `T:Copy` where `U:Copy` is expected...
     U <: T                     // ...so long as `U <: T`

text/0771-std-iter-once.md

@@ -12,7 +12,7 @@ This is a common task when working with iterators. Currently, this can be done i
 
 # Detailed design
 
-`once` will return a new struct, `std::iter::Once<T>`, implementing Iterator<T>. Internally, `Once<T>` is simply a newtype wrapper around `std::option::IntoIter<T>`. The actual body of `once` is thus trivial:
+`once` will return a new struct, `std::iter::Once<T>`, implementing `Iterator<T>`. Internally, `Once<T>` is simply a newtype wrapper around `std::option::IntoIter<T>`. The actual body of `once` is thus trivial:
 
 ```rust
 pub struct Once<T>(std::option::IntoIter<T>);

text/1228-placement-left-arrow.md

@@ -59,10 +59,10 @@ applied to the original `in (PLACE_EXPR) VALUE_EXPR` syntax):
 
  * [p1start](https://github.com/rust-lang/rfcs/pull/809#issuecomment-73837430)
 
-   > I’m not a fan of in <place> { <stmts> }, simply because the
+   > I’m not a fan of `in <place> { <stmts> }`, simply because the
    > requirement of a block suggests that it’s some kind of control
    > flow structure, or that all the statements inside will be
-   > somehow run ‘in’ the given <place> (or perhaps, as @m13253
+   > somehow run ‘in’ the given `<place>` (or perhaps, as @m13253
    > seems to have interpreted it, for all box expressions to go
    > into the given place). It would be our first syntactical
    > construct which is basically just an operator that has to

text/1298-incremental-compilation.md

@@ -247,7 +247,7 @@ I've uncovered a few fishy cases where we using the node id from
 external crates to index into the local crate's HIR map, which is
 certainly incorrect. --nmatsakis
 
-<a id="depgraph">
+<a id="depgraph"></a>
 ## Identifying and tracking dependencies
 
 ### Core idea: a fine-grained dependency graph

text/1398-kinds-of-allocators.md

@@ -166,10 +166,10 @@ So, an interaction between a program, a collection library, and an
 allocator might look like this:
 
 <img width="800" src="https://rawgit.com/pnkfelix/pnkfelix.github.com/69230e5f1ea140c0a09c5a9fdd7f0766207cdddd/Svg/allocator-msc.svg">
+
 If you cannot see the SVG linked here, try the [ASCII art version][ascii-art] appendix.
 Also, if you have suggestions for changes to the SVG, feel free to write them as a comment
 in that appendix; (but be sure to be clear that you are pointing out a suggestion for the SVG).
-</img>
 
 In general, an allocator might be the backing memory pool itself; or
 an allocator might merely be a *handle* that references the memory

text/1644-default-and-expanded-rustc-errors.md

@@ -251,8 +251,8 @@ subsequent style RFC.
 
 ## Expanded error messages
 
-Currently, --explain text focuses on the error code. You invoke the compiler with --explain
-<error code> and receive a verbose description of what causes errors of that number. The resulting
+Currently, --explain text focuses on the error code. You invoke the compiler with `--explain
+<error code>` and receive a verbose description of what causes errors of that number. The resulting
 message can be helpful, but it uses generic sample code which makes it feel less connected to the
 user's code.
 

text/2025-nested-method-calls.md

@@ -50,7 +50,7 @@ directions. See the Alternatives section for more details.
 ## Why do we get an error in the first place?
 
 You may wonder why this code isn't accepted in the first place. To see
-why, consider what the (somewhat simplified) resulting MIR looks like:
+why, consider what the (somewhat simplified[^simp]) resulting MIR looks like:
 
 [^simp]: This MIR is mildly simplified; the real MIR has multiple basic blocks to account for the possibility of panics.
 

text/2457-non-ascii-idents.md

@@ -65,7 +65,7 @@ Note: The supported Unicode version should be stated in the documentation.
 
 The lexer defines identifiers as:
 
-> **<sup>Lexer:<sup>**  
+> **<sup>Lexer:</sup>**
 > IDENTIFIER_OR_KEYWORD:  
 > &nbsp;&nbsp; XID_Start&nbsp;XID_Continue<sup>\*</sup>  
 > &nbsp;&nbsp; | `_` XID_Continue<sup>*</sup>  

text/3502-cargo-script.md

@@ -334,7 +334,7 @@ Inferred / defaulted manifest fields:
   manifest at the cost of potentially breaking scripts on rust upgrades
   - Warn when `edition` is unspecified.  Since piped commands are run with `--quiet`, this may not show up.
   - Based on feedback, we might add `cargo-<edition>` proxies to put in `#!` as a shorthand
-  - Based on feedback, we can switch to "edition is required as of <future> edition"
+  - Based on feedback, we can switch to "edition is required as of &lt;future&gt; edition"
 
 Note: As of [rust-lang/cargo#123](https://github.com/rust-lang/cargo/pull/12786),
 when `package.version` is missing,

text/3537-msrv-resolver.md

@@ -31,7 +31,7 @@ likely only needing to follow the FCP process.
 
 ## Status Quo
 
-<details><summary>Ensuring you have a `Cargo.lock` with dependencies compatible with your minimum-supported Rust version (MSRV) is an arduous task of running `cargo update <dep> --precise <ver>` until it works.</summary>
+<details><summary>Ensuring you have a <code>Cargo.lock</code> with dependencies compatible with your minimum-supported Rust version (MSRV) is an arduous task of running <code>cargo update &lt;dep&gt; --precise &lt;ver&gt;</code> until it works</summary>
 
 Let's step through a simple scenario where a user develops with the
 latest Rust version but production uses an older version:

text/3662-mergeable-rustdoc-cross-crate-info.md

@@ -135,7 +135,7 @@ $ tree . -a
 │       ├── static.files
 │           │   ├── COPYRIGHT-23e9bde6c69aea69.txt
 │           │   ├── favicon-2c020d218678b618.svg
-│           │   └── <rest of the contents excluded>
+│           │   └── &lt;rest of the contents excluded&gt;
 │       ├── trait-crate
 │       │   ├── all.html
 │       │   ├── index.html