We're going to have more modules under lint, and the paths get unwieldy. We
also plan to have lints run at multiple points in the compilation pipeline.

Fix #15052

The aim of these changes is not working out a generic bi-endianness architectures support but to allow people develop for little endian MIPS machines (issue #7190).

Fix #15052

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