Merge pull request #3878 from ehuss/markup-fixes

Apply several markup fixes

Author: Urgau

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.