Includes a bit more comments than usual for a regression test; I felt like documenting Niko's diagnosis of the original problem here. 

Fix #15111 

r? anyone.

If you define lang items in your crate, add `#[feature(lang_items)]`.

If you define intrinsics (`extern "rust-intrinsic"`), add
`#[feature(intrinsics)]`.

Closes #12858.

[breaking-change]

r? @brson

If you define lang items in your crate, add `#[feature(lang_items)]`.

If you define intrinsics (`extern "rust-intrinsic"`), add
`#[feature(intrinsics)]`.

Closes #12858.

[breaking-change]

This is just a cleanup of the code. Doesn't really change anything deep about the way we operate. This is a prelude to implementing a good solution for one-way matching for #5527.

r? @pnkfelix (we were just crawling about this code, after all)

This does not yet change the compiler and libraries from `*T` to `*const T` as
it will require a snapshot to do so.

cc #7362

---

Note that the corresponding RFC, https://github.com/rust-lang/rfcs/pull/68, has not yet been accepted. It was [discussed at the last meeting](https://github.com/rust-lang/rust/wiki/Meeting-weekly-2014-06-10#rfc-pr-68-unsafe-pointers-rename-t-to-const-t) and decided to be accepted, however. I figured I'd get started on the preliminary work for the RFC that will be required regardless.

`for...in`.

Closes #14803.

If you used a structure literal after one of these keywords, surround it
in parentheses.

[breaking-change]

r? @nick29581

`for...in`.

Closes #14803.

If you used a structure literal after one of these keywords, surround it
in parentheses.

[breaking-change]

Closes #3973.

Closes #3973.

Even if they used to test different things in the past, they are
now identical to other files.

Closes #11496

/usr/bin/env appears to be more portable.

Reject `struct Foo();` to fix #15095.

fix #12291

Turns out field names of struct variants are not encoded in crate metadata.

Closes #15031.

In other words, Late-bound regions that occur non-free should be
skipped.

Fix #10846 (specifically the ICE, not the weakness in the current type inference).

See http://static.rust-lang.org/doc/master/rustc/front/feature_gate/index.html for the problem this fixes.

This is a couple micro-optimizations I've been sitting on for a while. This inlines a couple functions that are important to the `std::io::mem`. Ultimately, this results in about a 15% performance increase in some micro-benchmarks for my [libserialize](https://github.com/erickt/rust-serde) rewrite.

Fixes #15080.

Some cleanups I'm sick of rebasing.

r? @pcwalton (do you agree with new names?)

Unit-like structs are written as `struct Foo;`, but we erroneously
accepted `struct Foo();` and took it to mean the same thing. Now we
don't, so use the `struct Foo;` form!

[breaking-change]

The #![feature(...)] line had been rendering in the docs as a header
because of Markdown syntax.

There were still Total{Ord,Eq} in docs and src/etc

Even if they used to test different things in the past, they are
now identical to other files.

Closes #11496

infrastructure that has been accidentally left out of the build
for a rather long time (it was still using `@DVec`!)

There were still Total{Ord,Eq} in docs and src/etc

In other words, Late-bound regions that occur non-free should be
skipped.

Fix #10846.

We currently compiled bools to i8 values, because there was a bug in
LLVM that sometimes caused miscompilations when using i1 in, for
example, structs.

Using i8 means a lot of unnecessary zero-extend and truncate operations
though, since we have to convert the value from and to i1 when using for
example icmp or br instructions. Besides the unnecessary overhead caused
by this, it also sometimes made LLVM miss some optimizations.

First, we have to fix some bugs concerning the handling of
attributes in foreign function declarations and calls. These
are required because the i1 type needs the ZExt attribute when
used as a function parameter or return type.

Then we have to update LLVM to get a bugfix without which LLVM
sometimes generates broken code when using i1.

And then, finally, we can switch bools over to i1.

This allows llvm to optimize away much of the overhead from using
the MemReader/MemWriters. My benchmarks showed it to shave 15% off
of my in progress serialization/json encoding.