auto merge of #7130 : huonw/rust/rustdoc-highlight, r=thestinger

This means that type definitions and function signatures have
pretty colours.
auto merge of #7147 : huonw/rust/vec-connect, r=Aatch

This is caused by StrVector having a generic implementation for &[S]
and so #5898 means that method resolution of ~[~[1]].concat() sees that
both StrVector and VectorVector have methods that (superficially) match.

They are now connect_vec and concat_vec, which means that they can actually be
called.
auto merge of #7148 : catamorphism/rust/rustpkg_tests, r=graydon

r? @graydon Automate more tests described in the commands.txt file,
and add infrastructure for running them. Right now, tests shell
out to call rustpkg. This is not ideal.

Goes part of the way towards addressing #5683
trans::glue: don't allocate a pointer variable if it already exists

Removes one alloca and store from the drop glue of @ boxes. This speeds
up the rustc build by 1s (might be noise, though).
Fix inlining of glue code

Currently, when calling glue functions, we cast the function to match
the argument type. This interacts very badly with LLVM and breaks
inlining of the glue code.

It's more efficient to use a unified function type for the glue
functions and always cast the function argument instead of the function.

The resulting code for rustc is about 13% faster (measured up to and
including the "trans" pass) and the resulting librustc is about 5%
smaller.
Add IterBytes impls for float/f32/f64. This allows creating
HashMaps with floats as keys.
trans::glue: don't generate struct destructors in the free glue

The free glue shouldn't be called for structs, and the drop glue already
contains the destructor.
Fix up mingw32 case
auto merge of #7154 : dotdash/rust/glue, r=graydon

Currently, when calling glue functions, we cast the function to match
the argument type. This interacts very badly with LLVM and breaks
inlining of the glue code.

It's more efficient to use a unified function type for the glue
functions and always cast the function argument instead of the function.

The resulting code for rustc is about 13% faster (measured up to and
including the "trans" pass) and the resulting librustc is about 5%
smaller.
Move trans mod items into trans/mod.rs
Move CrateContext into it's own file
Make CrateContext::new() fn.

Move construction of a CrateContext into a static method on
CrateContext.
Fix terminfo::param %i op
Remove @-fields from CrateContext

Remove all the explicit @mut-fields from CrateContext, though many
fields are still @-ptrs.
This required changing every single function call that explicitly
took a @CrateContext, so I took advantage and changed as many as I
could get away with to &-ptrs or &mut ptrs.
Fix Merge Fallout
iterator: add a `find` adaptor
iterator: add a `position` adaptor
iterator: work around method resolve bug
auto merge of #7124 : Aatch/rust/trans-refactor-pt1, r=brson

This removes all of the explicit `@mut` fields from `CrateContext`. There are still a few that are managed, but no longer do we have `@mut bool` in the structure.

Most of the changes are changing `@CrateContext` to `@mut CrateContext`, though I did change as many as I could get away with to `&CrateContext` and `&mut CrateContext`. The biggest thing preventing me from changing to `&[mut]` in most places was the instruction counter thing. In two cases, where I got a static borrow error and a dynamic borrow error, I opted to remove the count call there as it was literally the only thing preventing me from switching to `&mut CrateContext` parameters in both cases.

Other things to note:

* the EncoderContext uses borrowed pointers with lifetimes, since it can, though that required me to work around the limitation of not being able to move a structure with borrowed pointers into a heap closure. I changed as much as I could to stack closures, but unfortunately I hit the AST visitor and changing that is somewhat outside the scope of this PR. Instead (and there is a comment to this effect) I choose to unsafely get the structure into the heap, this is because I know the lifetimes involved are safe, even though the compiler can't prove it.

* Many of the changes are workarounds because of the borrow checker, either dynamically freezing it for too long, or inferring too large a scope. This is mostly just from nested function calls where each borrow is considered to last for the entire statement. Other cases are where `CrateContext` was borrowed in a `match` causing it to be borrowed for the entire length of the match, even though that wasn't wanted (or needed).

* I haven't yet tested to see if this changes compilation times in any way. I doubt there will be much of an impact however, as the only major improvements are less indirection and fewer refcount bumps.

* This lays the foundations to remove many more heap allocations in trans as many cases can be changed to use lifetimes instead.

=====

This change includes some other, minor refactorings, as I am planning a series, however I don't want to submit them all at once as it will be hell to continually rebase.
stop using an absolute rpath

This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.

Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.

The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.

http://wiki.debian.org/RpathIssue
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath