Remove feature gated examples from the reference

Fixes rust-lang#24573

Author: steveklabnik

src/doc/reference.md

@@ -973,28 +973,6 @@ Use declarations support a number of convenient shortcuts:
   and their immediate parent module, using the `self` keyword, such as
   `use a::b::{self, c, d};`
 
-An example of `use` declarations:
-
-```
-# #![feature(core)]
-use std::option::Option::{Some, None};
-use std::collections::hash_map::{self, HashMap};
-
-fn foo<T>(_: T){}
-fn bar(map1: HashMap<String, usize>, map2: hash_map::HashMap<String, usize>){}
-
-fn main() {
-    // Equivalent to 'foo(vec![std::option::Option::Some(1.0f64),
-    // std::option::Option::None]);'
-    foo(vec![Some(1.0f64), None]);
-
-    // Both `hash_map` and `HashMap` are in scope.
-    let map1 = HashMap::new();
-    let map2 = hash_map::HashMap::new();
-    bar(map1, map2);
-}
-```
-
 Like items, `use` declarations are private to the containing module, by
 default. Also like items, a `use` declaration can be public, if qualified by
 the `pub` keyword. Such a `use` declaration serves to _re-export_ a name. A
@@ -1030,35 +1008,6 @@ parent modules respectively. All rules regarding accessing declared modules in
 `use` declarations applies to both module declarations and `extern crate`
 declarations.
 
-An example of what will and will not work for `use` items:
-
-```
-# #![feature(core)]
-# #![allow(unused_imports)]
-use foo::core::iter;  // good: foo is at the root of the crate
-use foo::baz::foobaz;    // good: foo is at the root of the crate
-
-mod foo {
-    extern crate core;
-
-    use foo::core::iter; // good: foo is at crate root
-//  use core::iter;      // bad:  core is not at the crate root
-    use self::baz::foobaz;  // good: self refers to module 'foo'
-    use foo::bar::foobar;   // good: foo is at crate root
-
-    pub mod bar {
-        pub fn foobar() { }
-    }
-
-    pub mod baz {
-        use super::bar::foobar; // good: super refers to module 'foo'
-        pub fn foobaz() { }
-    }
-}
-
-fn main() {}
-```
-
 ### Functions
 
 A _function item_ defines a sequence of [statements](#statements) and an
@@ -1378,16 +1327,13 @@ a = Animal::Cat;
 Enumeration constructors can have either named or unnamed fields:
 
 ```
-# #![feature(struct_variant)]
-# fn main() {
 enum Animal {
     Dog (String, f64),
     Cat { name: String, weight: f64 }
 }
 
 let mut a: Animal = Animal::Dog("Cocoa".to_string(), 37.2);
 a = Animal::Cat { name: "Spotty".to_string(), weight: 2.7 };
-# }
 ```
 
 In this example, `Cat` is a _struct-like enum variant_,
@@ -1727,17 +1673,6 @@ Functions within external blocks are declared in the same way as other Rust
 functions, with the exception that they may not have a body and are instead
 terminated by a semicolon.
 
-```
-# #![feature(libc)]
-extern crate libc;
-use libc::{c_char, FILE};
-
-extern {
-    fn fopen(filename: *const c_char, mode: *const c_char) -> *mut FILE;
-}
-# fn main() {}
-```
-
 Functions within external blocks may be called by Rust code, just like
 functions defined in Rust. The Rust compiler automatically translates between
 the Rust ABI and the foreign ABI.
@@ -2339,7 +2274,7 @@ considered a full-fledged language feature.
 
 For this reason, Rust recognizes a special crate-level attribute of the form:
 
-```{.ignore}
+```ignore
 #![feature(feature1, feature2, feature3)]
 ```
 
@@ -3241,55 +3176,17 @@ expression.
 
 In a pattern whose head expression has an `enum` type, a placeholder (`_`)
 stands for a *single* data field, whereas a wildcard `..` stands for *all* the
-fields of a particular variant. For example:
-
-```
-#![feature(box_patterns)]
-#![feature(box_syntax)]
-enum List<X> { Nil, Cons(X, Box<List<X>>) }
-
-fn main() {
-    let x: List<i32> = List::Cons(10, box List::Cons(11, box List::Nil));
-
-    match x {
-        List::Cons(_, box List::Nil) => panic!("singleton list"),
-        List::Cons(..)               => return,
-        List::Nil                    => panic!("empty list")
-    }
-}
-```
-
-The first pattern matches lists constructed by applying `Cons` to any head
-value, and a tail value of `box Nil`. The second pattern matches _any_ list
-constructed with `Cons`, ignoring the values of its arguments. The difference
-between `_` and `..` is that the pattern `C(_)` is only type-correct if `C` has
-exactly one argument, while the pattern `C(..)` is type-correct for any enum
-variant `C`, regardless of how many arguments `C` has.
+fields of a particular variant. The difference between `_` and `..` is that the
+pattern `C(_)` is only type-correct if `C` has exactly one argument, while the
+pattern `C(..)` is type-correct for any enum variant `C`, regardless of how
+many arguments `C` has.
 
 Used inside an array pattern, `..` stands for any number of elements, when the
 `advanced_slice_patterns` feature gate is turned on. This wildcard can be used
 at most once for a given array, which implies that it cannot be used to
 specifically match elements that are at an unknown distance from both ends of a
 array, like `[.., 42, ..]`. If preceded by a variable name, it will bind the
-corresponding slice to the variable. Example:
-
-```
-# #![feature(advanced_slice_patterns, slice_patterns)]
-fn is_symmetric(list: &[u32]) -> bool {
-    match list {
-        [] | [_]                   => true,
-        [x, inside.., y] if x == y => is_symmetric(inside),
-        _                          => false
-    }
-}
-
-fn main() {
-    let sym     = &[0, 1, 4, 2, 4, 1, 0];
-    let not_sym = &[0, 1, 7, 2, 4, 1, 0];
-    assert!(is_symmetric(sym));
-    assert!(!is_symmetric(not_sym));
-}
-```
+corresponding slice to the variable.
 
 A `match` behaves differently depending on whether or not the head expression
 is an [lvalue or an rvalue](#lvalues,-rvalues-and-temporaries). If the head
@@ -3305,68 +3202,13 @@ possible, it is preferable to match on lvalues, as the lifetime of these
 matches inherits the lifetime of the lvalue, rather than being restricted to
 the inside of the match.
 
-An example of a `match` expression:
-
-```
-#![feature(box_patterns)]
-#![feature(box_syntax)]
-# fn process_pair(a: i32, b: i32) { }
-# fn process_ten() { }
-
-enum List<X> { Nil, Cons(X, Box<List<X>>) }
-
-fn main() {
-    let x: List<i32> = List::Cons(10, box List::Cons(11, box List::Nil));
-
-    match x {
-        List::Cons(a, box List::Cons(b, _)) => {
-            process_pair(a, b);
-        }
-        List::Cons(10, _) => {
-            process_ten();
-        }
-        List::Nil => {
-            return;
-        }
-        _ => {
-            panic!();
-        }
-    }
-}
-```
-
 Patterns that bind variables default to binding to a copy or move of the
 matched value (depending on the matched value's type). This can be changed to
 bind to a reference by using the `ref` keyword, or to a mutable reference using
 `ref mut`.
 
 Subpatterns can also be bound to variables by the use of the syntax `variable @
-subpattern`. For example:
-
-```
-#![feature(box_patterns)]
-#![feature(box_syntax)]
-
-enum List { Nil, Cons(u32, Box<List>) }
-
-fn is_sorted(list: &List) -> bool {
-    match *list {
-        List::Nil | List::Cons(_, box List::Nil) => true,
-        List::Cons(x, ref r @ box List::Cons(_, _)) => {
-            match *r {
-                box List::Cons(y, _) => (x <= y) && is_sorted(&**r),
-                _ => panic!()
-            }
-        }
-    }
-}
-
-fn main() {
-    let a = List::Cons(6, box List::Cons(7, box List::Cons(42, box List::Nil)));
-    assert!(is_sorted(&a));
-}
-
-```
+subpattern`.
 
 Patterns can also dereference pointers by using the `&`, `&mut` and `box`
 symbols, as appropriate. For example, these two matches on `x: &i32` are