Update extract-tests.py to use same test directives as rustdoc.

Closes rust-lang#11362.

Author: wting

AUTHORS.txt

@@ -351,7 +351,7 @@ Vincent Belliard <[email protected]>
 Vivek Galatage <[email protected]>
 Volker Mische <[email protected]>
 Wade Mealing <[email protected]>
-William Ting <william.h.ting@gmail.com>
+William Ting <io@williamting.com>
 Yasuhiro Fujii <[email protected]>
 Young-il Choi <[email protected]>
 Youngmin Yoo <[email protected]>

doc/complement-cheatsheet.md

@@ -48,7 +48,7 @@ let y: i64 = x.unwrap();
 
 Use [`File::open`](http://static.rust-lang.org/doc/master/std/io/fs/struct.File.html#method.open) to create a [`File`](http://static.rust-lang.org/doc/master/std/io/fs/struct.File.html) struct, which implements the [`Reader`](http://static.rust-lang.org/doc/master/std/io/trait.Reader.html) trait.
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 use std::path::Path;
 use std::io::fs::File;
 
@@ -168,7 +168,7 @@ let _ = close(Door::<Open>(~"front"));
 
 Attempting to close a closed door is prevented statically:
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 let _ = close(Door::<Closed>(~"front")); // error: mismatched types: expected `main::Door<main::Open>` but found `main::Door<main::Closed>`
 ~~~
 
@@ -196,7 +196,7 @@ Window* createWindow(int width, int height);
 
 You can use a zero-element `enum` ([phantom type](#how-do-i-express-phantom-types)) to represent the opaque object handle. The FFI would look like this:
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 enum Window {}
 extern "C" {
     fn createWindow(width: c_int, height: c_int) -> *Window;

doc/guide-conditions.md

@@ -45,7 +45,6 @@ An example program that does this task reads like this:
 
 ~~~~
 # #[allow(unused_imports)];
-# extern mod extra;
 use std::io::{BufferedReader, File};
 # mod BufferedReader {
 #     use std::io::File;
@@ -243,7 +242,6 @@ and trapping its exit status using `task::try`:
 
 ~~~~
 # #[allow(unused_imports)];
-# extern mod extra;
 use std::io::{BufferedReader, File};
 use std::task;
 # mod BufferedReader {
@@ -347,7 +345,6 @@ but similarly clear as the version that used `fail!` in the logic where the erro
 
 ~~~~
 # #[allow(unused_imports)];
-# extern mod extra;
 use std::io::{BufferedReader, File};
 # mod BufferedReader {
 #     use std::io::File;
@@ -416,7 +413,6 @@ and replaces bad input lines with the pair `(-1,-1)`:
 
 ~~~~
 # #[allow(unused_imports)];
-# extern mod extra;
 use std::io::{BufferedReader, File};
 # mod BufferedReader {
 #     use std::io::File;
@@ -491,7 +487,6 @@ Changing the condition's return type from `(int,int)` to `Option<(int,int)>` wil
 
 ~~~~
 # #[allow(unused_imports)];
-# extern mod extra;
 use std::io::{BufferedReader, File};
 # mod BufferedReader {
 #     use std::io::File;
@@ -576,8 +571,7 @@ This can be encoded in the handler API by introducing a helper type: `enum Malfo
 
 ~~~~
 # #[allow(unused_imports)];
-# extern mod extra;
-use std::io::File;
+use std::io::{BufferedReader, File};
 # mod BufferedReader {
 #     use std::io::File;
 #     use std::io::MemReader;
@@ -700,7 +694,6 @@ a second condition and a helper function will suffice:
 
 ~~~~
 # #[allow(unused_imports)];
-# extern mod extra;
 use std::io::{BufferedReader, File};
 # mod BufferedReader {
 #     use std::io::File;

doc/guide-container.md

@@ -270,7 +270,7 @@ Containers can provide conversion from iterators through `collect` by
 implementing the `FromIterator` trait. For example, the implementation for
 vectors is as follows:
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 impl<A> FromIterator<A> for ~[A] {
     pub fn from_iterator<T: Iterator<A>>(iterator: &mut T) -> ~[A] {
         let (lower, _) = iterator.size_hint();
@@ -288,7 +288,7 @@ impl<A> FromIterator<A> for ~[A] {
 The `Iterator` trait provides a `size_hint` default method, returning a lower
 bound and optionally on upper bound on the length of the iterator:
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 fn size_hint(&self) -> (uint, Option<uint>) { (0, None) }
 ~~~
 

doc/guide-ffi.md

@@ -11,7 +11,7 @@ snappy includes a C interface (documented in
 The following is a minimal example of calling a foreign function which will
 compile if snappy is installed:
 
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 use std::libc::size_t;
 
 #[link(name = "snappy")]
@@ -43,7 +43,7 @@ keeping the binding correct at runtime.
 
 The `extern` block can be extended to cover the entire snappy API:
 
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 use std::libc::{c_int, size_t};
 
 #[link(name = "snappy")]
@@ -76,7 +76,7 @@ vectors as pointers to memory. Rust's vectors are guaranteed to be a contiguous
 length is number of elements currently contained, and the capacity is the total size in elements of
 the allocated memory. The length is less than or equal to the capacity.
 
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 pub fn validate_compressed_buffer(src: &[u8]) -> bool {
     unsafe {
         snappy_validate_compressed_buffer(src.as_ptr(), src.len() as size_t) == 0
@@ -96,7 +96,7 @@ required capacity to hold the compressed output. The vector can then be passed t
 `snappy_compress` function as an output parameter. An output parameter is also passed to retrieve
 the true length after compression for setting the length.
 
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 pub fn compress(src: &[u8]) -> ~[u8] {
     unsafe {
         let srclen = src.len() as size_t;
@@ -116,7 +116,7 @@ pub fn compress(src: &[u8]) -> ~[u8] {
 Decompression is similar, because snappy stores the uncompressed size as part of the compression
 format and `snappy_uncompressed_length` will retrieve the exact buffer size required.
 
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 pub fn uncompress(src: &[u8]) -> Option<~[u8]> {
     unsafe {
         let srclen = src.len() as size_t;
@@ -263,7 +263,7 @@ to the C library and afterwards be invoked from there.
 A basic example is:
 
 Rust code:
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 extern fn callback(a:i32) {
     println!("I'm called from C with value {0}", a);
 }
@@ -283,7 +283,7 @@ fn main() {
 ~~~~
 
 C code:
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 typedef void (*rust_callback)(int32_t);
 rust_callback cb;
 
@@ -314,7 +314,7 @@ the notification. This will allow the callback to unsafely access the
 referenced Rust object.
 
 Rust code:
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 
 struct RustObject {
     a: i32,
@@ -346,7 +346,7 @@ fn main() {
 ~~~~
 
 C code:
-~~~~ {.xfail-test}
+~~~~ {.ignore}
 typedef void (*rust_callback)(int32_t);
 void* cb_target;
 rust_callback cb;
@@ -440,7 +440,7 @@ the `link_args` attribute. This attribute is applied to `extern` blocks and
 specifies raw flags which need to get passed to the linker when producing an
 artifact. An example usage would be:
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 #[link_args = "-foo -bar -baz"]
 extern {}
 ~~~
@@ -476,7 +476,7 @@ Foreign APIs often export a global variable which could do something like track
 global state. In order to access these variables, you declare them in `extern`
 blocks with the `static` keyword:
 
-~~~{.xfail-test}
+~~~{.ignore}
 use std::libc;
 
 #[link(name = "readline")]
@@ -494,7 +494,7 @@ Alternatively, you may need to alter global state provided by a foreign
 interface. To do this, statics can be declared with `mut` so rust can mutate
 them.
 
-~~~{.xfail-test}
+~~~{.ignore}
 use std::libc;
 use std::ptr;
 

doc/guide-lifetimes.md

@@ -299,7 +299,7 @@ _as soon as its owning reference changes or goes out of
 scope_. Therefore, a program like this is illegal (and would be
 rejected by the compiler):
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 fn example3() -> int {
     let mut x = ~X {f: 3};
     let y = &x.f;
@@ -346,7 +346,7 @@ modify the previous example to introduce additional owned pointers
 and structs, and the compiler will still be able to detect possible
 mutations:
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 fn example3() -> int {
     struct R { g: int }
     struct S { f: ~R }
@@ -524,7 +524,7 @@ the compiler accepts the function `get_x()`.
 To emphasize this point, let’s look at a variation on the example, this
 time one that does not compile:
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 struct Point {x: f64, y: f64}
 fn get_x_sh(p: @Point) -> &f64 {
     &p.x // Error reported here

doc/guide-pointers.md

@@ -21,7 +21,7 @@ fn succ(x: &int) -> int { *x + 1 }
 
 So I wrote this code to try it out:
 
-~~~rust{.xfail-test}
+~~~rust{.ignore}
 fn main() {
     let number = 5;
     let succ_number = succ(number);
@@ -261,7 +261,7 @@ program is very large and complicated.
 
 For example, let's say you're using an owned pointer, and you want to do this:
 
-~~~rust{.xfail-test}
+~~~rust{.ignore}
 struct Point {
     x: int,
     y: int,
@@ -369,7 +369,7 @@ This theory is called 'region pointers,' and involve a concept called
 'lifetimes'. Here's the simple explanation: would you expect this code to
 compile?
 
-~~~rust{.xfail-test}
+~~~rust{.ignore}
 fn main() {
     println!("{}", x);
     let x = 5;
@@ -398,7 +398,7 @@ Here, we're borrowing a pointer to `x` inside of the `if`. The compiler, however
 is able to determine that that pointer will go out of scope without `x` being
 mutated, and therefore, lets us pass. This wouldn't work:
 
-~~~rust{.xfail-test}
+~~~rust{.ignore}
 fn main() {
     let mut x = ~5;
     if *x < 10 {

doc/guide-tasks.md

@@ -190,7 +190,7 @@ senders cannot use a single `Chan`, and multiple receivers cannot use a single
 `Port`.  What if our example needed to compute multiple results across a number
 of tasks? The following program is ill-typed:
 
-~~~ {.xfail-test}
+~~~ {.ignore}
 # use std::task::{spawn};
 # fn some_expensive_computation() -> int { 42 }
 let (port, chan) = Chan::new();
@@ -413,7 +413,7 @@ pattern-match on a result to check whether it's an `Ok` result with an `int`
 field (representing a successful result) or an `Err` result (representing
 termination with an error).
 
-~~~{.xfail-test .linked-failure}
+~~~{.ignore .linked-failure}
 # use std::task;
 # fn some_condition() -> bool { false }
 # fn calculate_result() -> int { 0 }
@@ -463,7 +463,7 @@ that repeatedly receives a `uint` message, converts it to a string, and sends
 the string in response.  The child terminates when it receives `0`.
 Here is the function that implements the child task:
 
-~~~{.xfail-test .linked-failure}
+~~~{.ignore .linked-failure}
 # use extra::comm::DuplexStream;
 # use std::uint;
 fn stringifier(channel: &DuplexStream<~str, uint>) {
@@ -486,7 +486,7 @@ response itself is simply the stringified version of the received value,
 
 Here is the code for the parent task:
 
-~~~{.xfail-test .linked-failure}
+~~~{.ignore .linked-failure}
 # use std::task::spawn;
 # use std::uint;
 # use extra::comm::DuplexStream;

doc/po/ja/complement-cheatsheet.md.po

@@ -112,7 +112,7 @@ msgstr "## 演算子"
 #: doc/complement-cheatsheet.md:54
 #, fuzzy
 #| msgid "~~~~ use std::task::spawn;"
-msgid "~~~ {.xfail-test} use std::path::Path; use std::io::fs::File;"
+msgid "~~~ {.ignore} use std::path::Path; use std::io::fs::File;"
 msgstr ""
 "~~~~\n"
 "use std::task::spawn;"

doc/po/ja/guide-ffi.md.po

@@ -34,7 +34,7 @@ msgstr "[他言語間インターフェース (foreign function inferface)][ffi]
 #: doc/guide-ffi.md:16
 #, fuzzy
 #| msgid "~~~~ use std::task::spawn;"
-msgid "~~~~ {.xfail-test} use std::libc::size_t;"
+msgid "~~~~ {.ignore} use std::libc::size_t;"
 msgstr ""
 "~~~~\n"
 "use std::task::spawn;"
@@ -43,7 +43,7 @@ msgstr ""
 #: doc/guide-ffi.md:48
 #, fuzzy
 #| msgid "~~~~ use std::task::spawn;"
-msgid "~~~~ {.xfail-test} use std::libc::{c_int, size_t};"
+msgid "~~~~ {.ignore} use std::libc::{c_int, size_t};"
 msgstr ""
 "~~~~\n"
 "use std::task::spawn;"
@@ -67,7 +67,7 @@ msgstr ""
 #: doc/guide-ffi.md:344
 #, fuzzy
 #| msgid "~~~~ use std::task::spawn;"
-msgid "~~~{.xfail-test} use std::libc;"
+msgid "~~~{.ignore} use std::libc;"
 msgstr ""
 "~~~~\n"
 "use std::task::spawn;"
@@ -76,7 +76,7 @@ msgstr ""
 #: doc/guide-ffi.md:363
 #, fuzzy
 #| msgid "~~~~ use std::task::spawn;"
-msgid "~~~{.xfail-test} use std::libc; use std::ptr;"
+msgid "~~~{.ignore} use std::libc; use std::ptr;"
 msgstr ""
 "~~~~\n"
 "use std::task::spawn;"