std::rt: require known stack bounds for all tasks.

We just approximate with a 1 or 2 MB stack for native::start.
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
Fix CodeMap issue in expand_include_str()
auto merge of #11401 : michaelwoerister/rust/issue11322, r=alexcrichton

`expand_include_str()` in libsyntax seems to have corrupted the CodeMap by always setting the BytePos of any included files to zero. It now uses `CodeMap::new_filemap()` which should set everything properly. This should fix issue #11322 but I don't want to close it before I have confirmation from the reporters that the problem is indeed fixed.
Robustly read remaining bytes in a character

Closes #11372
auto merge of #11375 : alexcrichton/rust/issue-11372, r=pcwalton

Closes #11372
Fix windows installer version to be less verbose
Update some copyright dates
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