None of the builtin lints use this, and it's now available through the Context.

In preparation for the next commit.

It wasn't a very appropriate use of the trait. Instead, just enumerate
unit structs and those with a `fn new()` separately.

Also change some code formatting.

lint::builtin becomes a sibling of lint::context in order to ensure that lints
implemented there use the same public API as lint plugins.

The immediate benefits are

* moving the state specific to a single lint out of Context, and
* replacing the soup of function calls in the Visitor impl with
  more structured control flow

But this is also a step towards loadable lints.

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).