Add unwrap method to MoveItems
rustc: Refactor middle::trans::inline
Fix ICE with trans of calls to foreign fns

It was failing occasionally.
mark win32 binaries as large address aware

By default, 32-bit Windows executables are restricted to 2GiB of address
space even when running on 64-bit Windows when 4GiB is available.

Closes #17043
Register snapshots.

Closes #16880.
Forbid unsized rvalues

Closes #16813
auto merge of #16933 : nick29581/rust/dst-rvalue, r=nikomatsakis

Closes #16813 

r? @nikomatsakis I feel like I should be checking more things in check_rvalues, but not sure what - I don't properly understand expr_use_visitor
auto merge of #17036 : pczarn/rust/issue-15913-ICE-with-call-trans, r=alexcrichton

A match in callee.rs was recognizing some foreign fns as named tuple constructors. A reproducible test case for this is nearly impossible since it depends on the way NodeIds happen to be assigned in different crates.

Fixes #15913
auto merge of #17063 : huonw/rust/snap, r=alexcrichton

Closes #16880.
auto merge of #17053 : thestinger/rust/large_address_aware, r=sfackler,cmr

By default, 32-bit Windows executables are restricted to 2GiB of address
space even when running on 64-bit Windows when 4GiB is available.

Closes #17043
rustc: use a TypedArena to allocate types in the type context.
rustc: fix fallout from the addition of a 'tcx lifetime on tcx.
rustc: fix fallout from the addition of a 'tcx lifetime on trans::Block.
rustdoc: fix fallout from the addition of a 'tcx lifetime on tcx.
auto merge of #16903 : mahkoh/rust/move_items_unwrap, r=aturon

Closes #16879
auto merge of #12809 : eddyb/rust/ty-arena, r=cmr

This was inspired by seeing a LLVM flatline of **~600MB** when running rustc with jemalloc (each type's `t_box_` is allocated on the heap, creating a lot of fragmentation, which jemalloc can deal with, unlike glibc).
std: Turn down the stdout chunk size

I've found that 64k is still too much and continue to see the errors as reported
in #14940. I've locally found that 32k fails, and 24k succeeds, so I've trimmed
the size down to 8192 which libuv happens to use as well.

It sounds like the limit can still be hit with many threads in play, but I have
yet to reproduce this, so I figure we can wait until that's hit (if it's
possible) and then take action.
auto merge of #16952 : alexcrichton/rust/windows-large-console-write, r=brson

I've found that 64k is still too much and continue to see the errors as reported
in #14940. I've locally found that 32k fails, and 24k succeeds, so I've trimmed
the size down to 10000 which the included links in the added comment end up
recommending.

It sounds like the limit can still be hit with many threads in play, but I have
yet to reproduce this, so I figure we can wait until that's hit (if it's
possible) and then take action.
micro-optimize dynamic allocation alignment

Previously, some parts of this optimization were impossible because the
alignment passed to the free function was not correct. That was fully
fixed by #17012.

Closes #17092