This pattern is used in a couple places, so it'd be nice
to abstract it away.

Issue #1736

My gcc won't let the result of this function be ignored.

Make process-spawning take environments and working directories, remove procsrv task from compiletest.

* Renamed str::split -> str::split_byte
* Renamed str::splitn -> str::splitn_byte
* Renamed str::split_func -> str::split
* Renamed str::split_char -> str::split_char
* Renamed str::split_chars_iter -> str::split_char_iter
* Added u8::is_ascii
* Fixed the behavior of str::split_str, so that it matches split_chars
  and split (i.e. ["", "XXX", "YYY", ""] == split_str(".XXX.YYY.", "."))
* Fixed str::split_byte and str::splitn_byte so that they handle
  splitting UTF-8 strings on a given UTF-8/ASCII byte and also handle ""
  as the others do

There's no such thing anymore, we can simply call upcalls.cmp_type.

The free glue for opaque boxes will pick the actual tydesc out of the
box, and call its glue.

Issue #1736

This is causing mysterious hangs on windows. Issue #1769.

This reverts commit d65eabd5.

And remove the part about reserved words.

Closes #1728

Comments out a section of debuginfo.rs. This code was already broken
(only being called when --xg was passed, and only working on trivial
programs).

It is now no longer needed to have a ty::ctxt to get at the contents
of a ty::t. The straight-forward approach of doing this, simply making
ty::t a box type, unfortunately killed our compiler performance (~15%
slower) through refcounting cost. Thus, this patch now represents
ty::t as an unsafe pointer, assuming that the ty::ctxt, which holds
these boxes alive, outlives any uses of the ty::t values. In the
current compiler this trivially holds, but it is does of course add a
new potential pitfall.

ty::get takes a ty::t and returns a boxed representation of the type.
I've changed calls to ty::struct(X) to do ty::get(X).struct. Type
structs are full of vectors, and copying them every time we wanted to
access them was a bit of a cost.

Closes #1761

This allows a 'Name:' to appear in front of an iface declaration's
name, which will cause 'Name' to refer to the self type (with the same
number of type parameters as the iface has) in the method signatures
of the iface. For example:

    iface F: functor<A> {
        fn fmap<B>(f: fn(A) -> B) -> F<B>;
    }

Issue #1718

There is no valid expression that starts with a dot token (.5 is a number token),
so this introduces no ambiguities.

Issue #1716