Remove unnecessary substitution of type params when generating
vtable methods before translating the ref to the method itself.
librustc: Move block contexts into per-function arenas, and
stack-allocate function contexts.
Fixed Gc::clone, implemented Gc::ptr_eq
Merge some numeric traits with Real and don't re-export RealExt

The methods contained in `std::num::{Algebraic, Trigonometric, Exponential, Hyperbolic}` have now been moved into `std::num::Real`. This is part of an ongoing effort to simplify `std::num` (see issue #10387).

`std::num::RealExt` has also been removed from the prelude because it is not a commonly used trait.
Remove ApproxEq and assert_approx_eq!

This trait seems to stray too far from the mandate of a standard library as implementations may vary between use cases.
auto merge of #11369 : kvark/rust/master, r=huonw

-Fixed Gc::clone to not require a Clone implementation for T
-Implemented Gc::ptr_eq to match Rc::ptr_eq, added a test for that
Start the span for a path in a view_path at the correct place (at the start of the path, rather than at the start of the view_path).
Remove the io::Decorator trait

This is just an unnecessary trait that no one's ever going to parameterize over
and it's more useful to just define the methods directly on the types
themselves. The implementors of this type almost always don't want
inner_mut_ref() but they're forced to define it as well.
auto merge of #11386 : rcatolino/rust/ice-10955, r=pcwalton

So, like I mentioned in issue #10955 it doesn't seem like we need to call ```ty::subst_tps``` when the method is generic. But then I realized that this function doesn't mutate any of its input, and the return value is unused. Plus the type param substitution seems to be taken care of in ```trans_fn_ref_with_vtables```, so I thought I'd just try to remove it. As far as I can tell everything works.

This closes #10955.
auto merge of #11387 : pcwalton/rust/de-at-block, r=alexcrichton

r? @brson
auto merge of #11394 : alexcrichton/rust/no-decorator, r=cmr

This is just an unnecessary trait that no one's ever going to parameterize over
and it's more useful to just define the methods directly on the types
themselves. The implementors of this type almost always don't want
inner_mut_ref() but they're forced to define it as well.
auto merge of #11402 : bjz/rust/remove-approx, r=alexcrichton

This trait seems to stray too far from the mandate of a standard library as implementations may vary between use cases. Third party libraries should implement their own if they need something like it.

This closes #5316.

r? @alexcrichton, @pcwalton
auto merge of #11412 : bjz/rust/num-cleanups, r=alexcrichton

The methods contained in `std::num::{Algebraic, Trigonometric, Exponential, Hyperbolic}` have now been moved into `std::num::Real`. This is part of an ongoing effort to simplify `std::num` (see issue #10387).

`std::num::RealExt` has also been removed from the prelude because it is not a commonly used trait.

r? @alexcrichton
auto merge of #11414 : nick29581/rust/span, r=alexcrichton

...at the start of the path, rather than at the start of the view_path.

Fixes #11317
Remove eof() from io::Reader
auto merge of #11376 : alexcrichton/rust/remove-eof, r=pcwalton

This is something I have been meaning to do for awhile, but upon inspection of the `eof` method on all of the `Reader` impls you may find some interesting surprises. The method returns a good answer for almost all wrapped I/O objects (buffered readers, mem readers, util readers, etc), but the actual return value on all I/O objects themselves is almost always useless.

Almost no I/O object other than a file actually knows when it's hit EOF or not. I think that pretending that all objects know when they've hit the end when almost none do is probably a bad idea. I can't really come up with a good answer to "is this file descriptor at eof" or "is this tcp stream at eof" much less "is this udp socket at eof". Due to being unable to answer these questions for *all* readers, I believe that it shouldn't be a part of the core `Reader` trait.
libsyntax: Renamed types, traits and enum variants to CamelCase.
Updated librustdoc and librustpkg to use the proper UpperCase names from libsyntax.
auto merge of #11417 : eddyb/rust/desnaking, r=bstrie
Implement the #[boot] attribute

Before this patch there was no ability to link to both libnative and libgreen
and specify which should be used to boot the main function. This commit moves
this logic into a #[boot] attribute which can allow control over this. The
changes made are:

1. The lang_start function is moved back into libstd with the signature:
   fn(*u8, *u8, int, *u8) or (main, boot, argc, argv)
2. Functions can now be tagged with #[boot] to indicate that the function can be
   used to boot a rust crate. This boot function is serialized to metadata.
3. Imports of external modules can also be tagged with #[boot] to indicate that
   the crate's boot-function should be used to boot the runtime
4. Only one #[boot] function/crate is allowed in an executable, more than one is
   an error (along with zero as well).
5. The compiler will automatically inject '#[boot] extern mod green;' for now,
   this can be overrided with #[no_boot].

With this new attribute, control over how a crate boots can be fine-tuned per
executable and libraries can specify arbitrary boot functions. The boot function
is purely responsible for dictating what context the 'main' function is run in,
runtime initialization via rt::init is not the responsibility of the boot
function. Finally, the boot function is also responsible for blocking until all
rust tasks have exited.