libsyntax: don't parse ////, /***/ as doc comments
rt: get rid of rust_fn and replace with fn_env_pair plus a little cleanup.
rt: take into account alignment for debug_opaque. Closes #2667
rt: Fix alignment in debug_opaque
made licenseck.py work for year substitutions
update tutorial and manual to use new `impl Trait for Type` syntax
Remove DVec from syntax::parse
Remove DVec from check_const
Remove DVec from json
Remove DVec from workcache
libcore: Move the numeric operations out of Num. r=brson

Sadly I could not use trait inheritance due to a type parameter substitution
bug.
auto merge of #4910 : pcwalton/rust/num-simplification, r=pcwalton

Sadly I could not use trait inheritance due to a type parameter substitution
bug.

r? @brson
auto merge of #4915 : luqmana/rust/rt-cleanup, r=pcwalton

Closes #1190.

Also, got rid of `rust_ptr_eq` since it isn't used any as well the `RUST_REFCOUNTED` macros.

Fixes #2667: alignment & wrong structure.
auto merge of #4925 : cpeterso/rust/docs-impl-trait-for-type, r=pcwalton

Replace `impl Type: Trait` with `impl Trait for Type` throughout tutorial and manual.
librustc: Replace `impl Type : Trait` with `impl Trait for Type`. rs=implflipping
stop applying noinline to glue code
auto merge of #4931 : thestinger/rust/glue, r=pcwalton

Using `noinline` causes a 3-10% hit in performance for most compiled Rust code. For the TreeMap it's ~15% and that's where I first noticed it.

Removing the noinline attribute doesn't slow down unoptimized builds, but it does significantly increase the time spent in LLVM passes for optimized builds. The improved speed of the compiler actually improves compile-times when optimization is off.

However, the reason for the increase is because more optimization is being done - I'm sure it would speed up compiles to mark *everything* with noinline, but it wouldn't be a good idea.

LLVM is clever enough with the inlining heuristics that this doesn't cause a notable increase in code size - some code becomes a bit bigger, some becomes a bit smaller. There are some cases where it's able to strip out a ton of code thanks to inlining.

I tried out `optsize` for glue code instead but it caused the same hit for LLVM passes in the compile time and the compiled code was a bit slower than just trusting LLVM to make the decisions.

* [TIME_PASSES=1 benchmarks](http://ompldr.org/vaGdxaA) (showing the performance increase in `rustc` and also the extra time spent in LLVM passes for more optimization)
stop zeroing all exchange allocations
rm unused zero param in C++ exchange allocator
Remove all final references to die!