Fix syntax::ext::deriving{,::*} docs formatting.

The most significant fix is for `syntax::ext::deriving::encodable`,
where one of the blocks of code, auspiciously containing `<S>` (recall
that Markdown allows arbitrary HTML to be contained inside it), was not
formatted as a code block, with a fun but messy effect.

Author: chris-morgan

src/libsyntax/ext/deriving/decodable.rs

@@ -9,7 +9,7 @@
 // except according to those terms.
 
 /*!
-The compiler code necessary for #[deriving(Decodable)]. See
+The compiler code necessary for `#[deriving(Decodable)]`. See
 encodable.rs for more.
 */
 

src/libsyntax/ext/deriving/encodable.rs

@@ -10,20 +10,20 @@
 
 /*!
 
-The compiler code necessary to implement the #[deriving(Encodable)]
-(and Decodable, in decodable.rs) extension.  The idea here is that
-type-defining items may be tagged with #[deriving(Encodable,
-Decodable)].
+The compiler code necessary to implement the `#[deriving(Encodable)]`
+(and `Decodable`, in decodable.rs) extension.  The idea here is that
+type-defining items may be tagged with `#[deriving(Encodable, Decodable)]`.
 
 For example, a type like:
 
 ```ignore
-    #[deriving(Encodable, Decodable)]
-    struct Node {id: uint}
+#[deriving(Encodable, Decodable)]
+struct Node { id: uint }
 ```
 
 would generate two implementations like:
 
+```ignore
 impl<S:serialize::Encoder> Encodable<S> for Node {
     fn encode(&self, s: &S) {
         s.emit_struct("Node", 1, || {
@@ -41,13 +41,14 @@ impl<D:Decoder> Decodable for node_id {
         })
     }
 }
+```
 
 Other interesting scenarios are whe the item has type parameters or
 references other non-built-in types.  A type definition like:
 
 ```ignore
-    #[deriving(Encodable, Decodable)]
-    struct spanned<T> {node: T, span: Span}
+#[deriving(Encodable, Decodable)]
+struct spanned<T> { node: T, span: Span }
 ```
 
 would yield functions like:

src/libsyntax/ext/deriving/generic.rs

@@ -16,6 +16,7 @@ access to the fields of the 4 different sorts of structs and enum
 variants, as well as creating the method and impl ast instances.
 
 Supported features (fairly exhaustive):
+
 - Methods taking any number of parameters of any type, and returning
   any type, other than vectors, bottom and closures.
 - Generating `impl`s for types with type parameters and lifetimes
@@ -59,7 +60,7 @@ associated with. It is only not `None` when the associated field has
 an identifier in the source code. For example, the `x`s in the
 following snippet
 
-~~~notrust
+```rust
 struct A { x : int }
 
 struct B(int);
@@ -68,7 +69,7 @@ enum C {
     C0(int),
     C1 { x: int }
 }
-~~~
+```
 
 The `int`s in `B` and `C0` don't have an identifier, so the
 `Option<ident>`s would be `None` for them.
@@ -83,7 +84,7 @@ variants, it is represented as a count of 0.
 
 The following simplified `Eq` is used for in-code examples:
 
-~~~notrust
+```rust
 trait Eq {
     fn eq(&self, other: &Self);
 }
@@ -92,7 +93,7 @@ impl Eq for int {
         *self == *other
     }
 }
-~~~
+```
 
 Some examples of the values of `SubstructureFields` follow, using the
 above `Eq`, `A`, `B` and `C`.

src/libsyntax/ext/deriving/mod.rs

@@ -9,10 +9,10 @@
 // except according to those terms.
 
 /*!
-The compiler code necessary to implement the #[deriving] extensions.
+The compiler code necessary to implement the `#[deriving]` extensions.
 
 
-FIXME (#2810)--Hygiene. Search for "__" strings (in other files too).
+FIXME (#2810): hygiene. Search for "__" strings (in other files too).
 We also assume "extra" is the standard library, and "std" is the core
 library.