Implement FromStr for IpAddr and SocketAddr

Better than that in rt::uv::net, because it:

* handles invalid input explicitly, without fail!()
* parses socket address, not just IP
* handles various ipv4-in-ipv6 addresses, like 2001:db8:122:344::192.0.2.33
  (see http://tools.ietf.org/html/rfc6052 for example)
* rejects output like `127.0000000.0.1`
* does not allocate heap memory
* have unit tests
Use FromStr for IpAddr in rt::uv::net
Better documentation for --emit-llvm option.

Document possible use with -S option.
Hide stuff that are not used outside of _match.rs
Added testcases for `match` keyword

Added testcases for `match` keyword including test for issue #5625.
Fix bug in `match`ing struct patterns

Code that collects fields in struct-like patterns used to ignore
wildcard patterns like `Foo{_}`. But `enter_defaults` considered
struct-like patterns as default in order to overcome this
(accoring to my understanding of situation).

However such behaviour caused code like this:
```
enum E {
    Foo{f: int},
    Bar
}
let e = Bar;
match e {
    Foo{f: _f} => { /* do something (1) */ }
    _ => { /* do something (2) */ }
}
```
consider pattern `Foo{f: _f}` as default. That caused inproper behaviour
and even segfaults while trying to destruct `Bar` as `Foo{f: _f}`.
Issues: #5625 , #5530.

This patch fixes `collect_record_or_struct_fields` to split cases of
single wildcard struct-like pattern and no struct-like pattern at all.
Former case resolved with `enter_rec_or_struct` (and not with
`enter_defaults`).

Closes #5625.
Closes #5530.
Fix node hashes
std: run test fix for ARM android
mk: install.mk fix to specify ADB variables not adb
mk: test.mk fix to specify ADB variables not adb
env! syntax extension changes

env! aborts compilation of the specified environment variable is not
defined and takes an optional second argument containing a custom
error message. option_env! creates an Option<&'static str> containing
the value of the environment variable.

There are no run-pass tests that check the behavior when the environment
variable is defined since the test framework doesn't support setting
environment variables at compile time as opposed to runtime. However,
both env! and option_env! are used inside of rustc itself, which should
act as a sufficient test.

Close #2248
rustpkg: Eliminate a copy
Makefiles: make rustpkgtest depend on rustpkg executable
auto merge of #8336 : stepancheg/rust/socket-addr-from-str, r=brson

FromStr implemented from scratch.

It is overengineered a bit, however.

Old implementation handles errors by fail!()-ing. And it has bugs, like it accepts `127.0.0.1::127.0.0.1` as IPv6 address, and does not handle all ipv4-in-ipv6 schemes. So I decided to implement parser from scratch.
auto merge of #8350 : dim-an/rust/fix-struct-match, r=pcwalton

Code that collects fields in struct-like patterns used to ignore
wildcard patterns like `Foo{_}`. But `enter_defaults` considered
struct-like patterns as default in order to overcome this
(accoring to my understanding of situation).

However such behaviour caused code like this:
```
enum E {
    Foo{f: int},
    Bar
}
let e = Bar;
match e {
    Foo{f: _f} => { /* do something (1) */ }
    _ => { /* do something (2) */ }
}
```
consider pattern `Foo{f: _f}` as default. That caused inproper behaviour
and even segfaults while trying to destruct `Bar` as `Foo{f: _f}`.
Issues: #5625 , #5530.

This patch fixes `collect_record_or_struct_fields` to split cases of
single wildcard struct-like pattern and no struct-like pattern at all.
Former case resolved with `enter_rec_or_struct` (and not with
`enter_defaults`).

Closes #5625.
Closes #5530.
Remove redundant Ord method impls.

Basically, generic containers should not use the default methods since a
type of elements may not guarantees total order. str could use them
since u8's Ord guarantees total order. Floating point numbers are also
broken with the default methods because of NaN. Thanks for @thestinger.

Timespec also guarantees total order AIUI. I'm unsure whether
extra::semver::Identifier does so I left it alone. Proof needed.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
auto merge of #8357 : omasanori/rust/cleanup, r=alexcrichton

I feel it's time to eliminate them (and add some testcases.)
std: Fix perf of local allocations in newsched

Mostly optimizing TLS accesses to bring local heap allocation performance
closer to that of oldsched. It's not completely at parity but removing the
branches involved in supporting oldsched and optimizing pthread_get/setspecific
to instead use our dedicated TCB slot will probably make up for it.
auto merge of #8361 : alexcrichton/rust/fix-node-hashes-in-crates, r=thestinger

When running rusti 32-bit tests from a 64-bit host, these errors came up frequently. My best idea as to what was happening is:

1. First, if you hash the same `int` value on 32-bit and 64-bit, you will get two different hashes.
2. In a cross-compile situation, let's say x86_64 is building an i686 library, all of the hashes will be 64-bit hashes.
3. Then let's say you use the i686 libraries and then attempt to link against the same i686 libraries, because you're calculating hashes with a 32-bit int instead of a 64-bit one, you'll have different hashes and you won't be able to find items in the metadata (the items were generated with a 64-bit int).

This patch changes the items to always be hashed as an `i64` to preserve the hash value across architectures. Here's a nice before/after for this patch of the state of rusti tests

```
host   target  before  after
64     64      yes     yes
64     32      no      no (llvm assertion)
32     64      no      yes
32     32      no      no (llvm assertion)
```

Basically one case started working, but currently when the target is 32-bit LLVM is having a lot of problems generating code. That's another separate issue though.
Fix Ipv6Addr to_str for ::1:x.x.x.x addresses

Reported by luqmana@