These two lines are actually three.
Properly implement Show for EnumSet
`rustc main.rs` generates main binary file
Update error messages in compile-fail tests
Take core as a dependency on librlibc. This is needed so that it can
see the lang-items for Sized etc. @acrichto and @thestinger had no
objections.
Guts of the new trait matching algorithm, not yet in use
Port coherence to use the new trait matching code
trans -- stop tracking vtables precisely, instead recompute as needed.
typeck/kind -- stop using old trait framework.

- Unify the "well-formedness" checking that typeck was already doing with what
  was taking place in kind.
- Move requirements that things be sized into typeck.
- I left the checking on upvars in kind, though I think it should eventually be
  refactored into regionck (which would perhaps be renamed).

This reflects a general plan to convert typeck so that it registers
obligations or other pending things for conditions it cannot check
eventually. This makes it easier to identify all the conditions that
apply to an AST expression, but can also influence inference in somec
cases (e.g., `Send` implies `'static`, so I already had to promote a lot
of the checking that `kind.rs` was doing into typeck, this branch just
continues the process).
misc ppaux changes
add Send bound on impl because stricter trait checking requires it
silence various warnings in stdlib, no idea why they suddenly started
heap: rm out-of-date FIXMEs
heap: optimize EMPTY to avoid relocations

Sized deallocation makes it pointless to provide an address that never
overlaps with pointers returned by an allocator. Code can branch on the
capacity of the allocation instead of a comparison with this sentinel.

This improves the situation in #8859, and the remaining issues are only
from the logging API, which should be disabled by default in optimized
release builds anyway along with debug assertions. The remaining issues
are part of #17081.

Closes #8859
remove the closure_exchange_malloc lang item
Update docs to include Sized trait, which is needed
Change the last linux 64-bit snapshot

I'm rotating in some CentOS 5.10 bots so we *actually* build on Linux 2.6.18
like we advertise doing so. Currently the snapshots are incompatible with CentOS
5.10 due to snapshots requiring glibc 2.6 and CentOS 5.10 having glibc 2.5.

It turns out that rustc only requires *one* symbol from glibc 2.6, which is
`futimens`. The rust distribution itself does not use this symbol, but LLVM
conditionally detects it and then uses it. This symbol isn't even called as part
of the compilation process, so we don't even need it!

The new snapshot was generated following these instructions [1]:

1. Download the current x86_64 linux snapshot and unpack it.
2. Open the rustc binary in a hex editor.
3. Change the linkage against glibc 2.6 from strong to *weak*
4. Write changes and re-run src/etc/make-snapshot.py
5. Upload new tarball to S3

On CentOS 5.10 a warning is printed each time the snapshot runs that the symbol
cannot be found (anyone with glibc 2.6+ does not have this warning printed). The
key part is that we can *bootstrap* on CentOS 5.10 at this point. The next
snapshot will be naturally compatible with glibc 2.3 (even older!) and will not
need to be manually edited.

[1]: http://jamesbond3142.no-ip.org/wiki/wiki.cgi/NewAppsOnOldGlibc
auto merge of #17288 : alexcrichton/rust/change-snap, r=brson

I'm rotating in some CentOS 5.10 bots so we *actually* build on Linux 2.6.18
like we advertise doing so. Currently the snapshots are incompatible with CentOS
5.10 due to snapshots requiring glibc 2.6 and CentOS 5.10 having glibc 2.5.

It turns out that rustc only requires *one* symbol from glibc 2.6, which is
`futimens`. The rust distribution itself does not use this symbol, but LLVM
conditionally detects it and then uses it. This symbol isn't even called as part
of the compilation process, so we don't even need it!

The new snapshot was generated following these instructions [1]:

1. Download the current x86_64 linux snapshot and unpack it.
2. Open the rustc binary in a hex editor.
3. Change the linkage against glibc 2.6 from strong to *weak*
4. Write changes and re-run src/etc/make-snapshot.py
5. Upload new tarball to S3

On CentOS 5.10 a warning is printed each time the snapshot runs that the symbol
cannot be found (anyone with glibc 2.6+ does not have this warning printed). The
key part is that we can *bootstrap* on CentOS 5.10 at this point. The next
snapshot will be naturally compatible with glibc 2.3 (even older!) and will not
need to be manually edited.

[1]: http://jamesbond3142.no-ip.org/wiki/wiki.cgi/NewAppsOnOldGlibc
auto merge of #17280 : thestinger/rust/heap, r=pcwalton
auto merge of #17232 : untitaker/rust/patch-1, r=alexcrichton

The wording is correct if you consider that two of these lines were extracted from the original example. It still tripped me up while reading, so i just removed any reference to the linecount.