Add std::os::self_exe_name()
libnative: Implement get_host_addresses.
Set LD_LIBRARY_PATH on linux for c-dynamic-dylib test

Else, libfoo can't find libcfoo.so.

bar has an rpath, which lets it find libfoo.  But libfoo doesn't have an
rapth that tells it where to find libcfoo
native: Don't use timerfd on Android

It doesn't seem to exist.
Follow symlinks in sysroot

Before this commit, rustc looked in `dirname $0`/../lib for libraries
but that doesn't work when rustc is invoked through a symlink.

This commit makes rustc look in `dirname $(readlink $0)`/../lib, i.e.
it first canonicalizes the symlink before walking up the directory tree.

Fixes #3632.
Make check-summary.py support file globbing

Fixes the following error when executing `make check-lite`:

    Traceback (most recent call last):
      File "/home/bnoordhuis/src/rust/src/etc/check-summary.py", line 27, in <module>
        map(summarise, logfiles)
      File "/home/bnoordhuis/src/rust/src/etc/check-summary.py", line 10, in summarise
        with open(fname) as fd:
    IOError: [Errno 2] No such file or directory: 'tmp/*.log'
Fix typo in tutorial
Redo exported macro serialization

The old method of serializing the AST gives totally bogus spans if the
expansion of an imported macro causes compilation errors. The best
solution seems to be to serialize the actual textual macro definition
and load it the same way the std-macros are. I'm not totally confident
that getting the source from the CodeMap will always do the right thing,
but it seems to work in simple cases.
Make some borrow checker errors more user friendly

A mutable and immutable borrow place some restrictions on what you can
with the variable until the borrow ends. This commit attempts to convey
to the user what those restrictions are. Also, if the original borrow is
a mutable borrow, the error message has been changed (more specifically,
i. "cannot borrow `x` as immutable because it is also borrowed as
mutable" and ii. "cannot borrow `x` as mutable more than once" have
been changed to "cannot borrow `x` because it is already borrowed as
mutable").

In addition, this adds a (custom) span note to communicate where the
original borrow ends.
Make docs search results URL-addressable

This change adds two improvements to docs searching functionality.

First, search results will immediately be displayed when a ?search=searchterm
query string parameter is provided to any docs url.

Second, search results are now inserted into the browser history, allowing for
easier navigation between search results and docs pages.
Replace '*' by '..' in the doc of pattern matching
Add '@' subpattern binding and examples to manual and tutorial
auto merge of #11718 : ktt3ja/rust/borrowck-error-msg, r=brson

A mutable and immutable borrow place some restrictions on what you can
with the variable until the borrow ends. This commit attempts to convey
to the user what those restrictions are. Also, if the original borrow is
a mutable borrow, the error message has been changed (more specifically,
i. "cannot borrow `x` as immutable because it is also borrowed as
mutable" and ii. "cannot borrow `x` as mutable more than once" have
been changed to "cannot borrow `x` because it is already borrowed as
mutable").

In addition, this adds a (custom) span note to communicate where the
original borrow ends.

```rust
fn main() {
    match true {
        true => {
            let mut x = 1;
            let y = &x;
            let z = &mut x;
        }
        false => ()
    }
}

test.rs:6:21: 6:27 error: cannot borrow `x` as mutable because it is already borrowed as immutable
test.rs:6             let z = &mut x;
                              ^~~~~~
test.rs:5:21: 5:23 note: previous borrow of `x` occurs here; the immutable borrow prevents subsequent moves or mutable borrows of `x` until the borrow ends
test.rs:5             let y = &x;
                              ^~
test.rs:7:10: 7:10 note: previous borrow ends here
test.rs:3         true => {
test.rs:4             let mut x = 1;
test.rs:5             let y = &x;
test.rs:6             let z = &mut x;
test.rs:7         }
                  ^
```

```rust
fn foo3(t0: &mut &mut int) {
    let t1 = &mut *t0;
    let p: &int = &**t0;
}

fn main() {}

test.rs:3:19: 3:24 error: cannot borrow `**t0` because it is already borrowed as mutable
test.rs:3     let p: &int = &**t0;
                            ^~~~~
test.rs:2:14: 2:22 note: previous borrow of `**t0` as mutable occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `**t0` until the borrow ends
test.rs:2     let t1 = &mut *t0;
                       ^~~~~~~~
test.rs:4:2: 4:2 note: previous borrow ends here
test.rs:1 fn foo3(t0: &mut &mut int) {
test.rs:2     let t1 = &mut *t0;
test.rs:3     let p: &int = &**t0;
test.rs:4 }
          ^
```

For the "previous borrow ends here" note, if the span is too long (has too many lines), then only the first and last lines are printed, and the middle is replaced with dot dot dot:
```rust
fn foo3(t0: &mut &mut int) {
    let t1 = &mut *t0;
    let p: &int = &**t0;



}

fn main() {}

test.rs:3:19: 3:24 error: cannot borrow `**t0` because it is already borrowed as mutable
test.rs:3     let p: &int = &**t0;
                            ^~~~~
test.rs:2:14: 2:22 note: previous borrow of `**t0` as mutable occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `**t0` until the borrow ends
test.rs:2     let t1 = &mut *t0;
                       ^~~~~~~~
test.rs:7:2: 7:2 note: previous borrow ends here
test.rs:1 fn foo3(t0: &mut &mut int) {
...
test.rs:7 }
          ^
```

(Sidenote: the `span_end_note` currently also has issue #11715)
auto merge of #11720 : sfackler/rust/macro-export-source, r=alexcrichton

The old method of serializing the AST gives totally bogus spans if the
expansion of an imported macro causes compilation errors. The best
solution seems to be to serialize the actual textual macro definition
and load it the same way the std-macros are. I'm not totally confident
that getting the source from the CodeMap will always do the right thing,
but it seems to work in simple cases.
auto merge of #11742 : eminence/rust/dylib-test-fix, r=alexcrichton

On my Gentoo Linux machine, the c-dynamic-dylib test is failing, because libcfoo can't be found.  bar has a correct rpath for finding libfoo.so, but libfoo.so's rpath doesn't contain the right entries for finding libcfoo.


Below is the test failure on my machine.  This test pass with this commit:

```
maketest: c-dynamic-dylib
----- /storage/home/achin/devel/rust/src/test/run-make/c-dynamic-dylib/ --------------------
------ stdout ---------------------------------------------
make[1]: Entering directory `/storage/home/achin/devel/rust/src/test/run-make/c-dynamic-dylib'
gcc -Wall -Werror -g -fPIC -m64 -L /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib -c -o /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/libcfoo.o cfoo.c
gcc -Wall -Werror -g -fPIC -m64 -L /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib -o /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/libcfoo.so /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/libcfoo.o -shared
/storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/stage2/bin/rustc --out-dir /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib -L /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib foo.rs
/storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/stage2/bin/rustc --out-dir /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib -L /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib bar.rs
/storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/bar
rm /storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/libcfoo.o
make[1]: Leaving directory `/storage/home/achin/devel/rust/src/test/run-make/c-dynamic-dylib'

------ stderr ---------------------------------------------
/storage/home/achin/devel/rust/x86_64-unknown-linux-gnu/test/run-make/c-dynamic-dylib/bar: error while loading shared libraries: libcfoo.so: cannot open shared object file: No such file or directory
make[1]: *** [all] Error 127

------        ---------------------------------------------

```
Remove reexport field
auto merge of #11750 : bnoordhuis/rust/follow-rustc-symlink, r=thestinger

Before this commit, rustc looked in `dirname $0`/../lib for libraries
but that doesn't work when rustc is invoked through a symlink.

This commit makes rustc look in `dirname $(readlink $0)`/../lib, i.e.
it first canonicalizes the symlink before walking up the directory tree.

Fixes #3632.
auto merge of #11753 : misfo/rust/patch-1, r=pcwalton
Move macro_rules! macros to libstd

They all have to go into a single module at the moment unfortunately.
Ideally, the logging macros would live in std::logging, condition! would
live in std::condition, format! in std::fmt, etc. However, this
introduces cyclic dependencies between those modules and the macros they
use which the current expansion system can't deal with. We may be able
to get around this by changing the expansion phase to a two-pass system
but that's for a later PR.

Closes #2247
cc #11763
Delete ignore! macro

This was a holdover from when we didn't allow nested comment blocks
(think #if 0). It isn't used anywhere.