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

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]

`for...in`.

Closes #14803.

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

[breaking-change]

Closes #3973.

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.

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.

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.

Generally speaking, inlining doesn't really help out with
constructing vectors, except for when we construct a zero-sized
vector. This patch allows llvm to optimize this case away in
a lot of cases, which shaves off 4-8ns. It's not much, but it
might help in some inner loop somewhere.

before:

running 12 tests
test bench_extend_0          ... bench:       123 ns/iter (+/- 6)
test bench_extend_5          ... bench:       323 ns/iter (+/- 11)
test bench_from_fn_0         ... bench:         7 ns/iter (+/- 0)
test bench_from_fn_5         ... bench:        49 ns/iter (+/- 6)
test bench_from_iter_0       ... bench:        11 ns/iter (+/- 0)
test bench_from_iter_5       ... bench:       176 ns/iter (+/- 11)
test bench_from_slice_0      ... bench:         8 ns/iter (+/- 1)
test bench_from_slice_5      ... bench:        73 ns/iter (+/- 5)
test bench_new               ... bench:         0 ns/iter (+/- 0)
test bench_with_capacity_0   ... bench:         6 ns/iter (+/- 1)
test bench_with_capacity_100 ... bench:        41 ns/iter (+/- 3)
test bench_with_capacity_5   ... bench:        40 ns/iter (+/- 2)

after:

test bench_extend_0          ... bench:       123 ns/iter (+/- 7)
test bench_extend_5          ... bench:       339 ns/iter (+/- 27)
test bench_from_fn_0         ... bench:         7 ns/iter (+/- 0)
test bench_from_fn_5         ... bench:        54 ns/iter (+/- 4)
test bench_from_iter_0       ... bench:        11 ns/iter (+/- 1)
test bench_from_iter_5       ... bench:       182 ns/iter (+/- 16)
test bench_from_slice_0      ... bench:         4 ns/iter (+/- 0)
test bench_from_slice_5      ... bench:        62 ns/iter (+/- 3)
test bench_new               ... bench:         0 ns/iter (+/- 0)
test bench_with_capacity_0   ... bench:         0 ns/iter (+/- 0)
test bench_with_capacity_100 ... bench:        41 ns/iter (+/- 1)
test bench_with_capacity_5   ... bench:        41 ns/iter (+/- 3)

Closes #15031.

Fixes #15080.

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.

Fixes #8106.

To fix #8106, we need an LLVM version that contains r211082 aka 0dee6756
which fixes a bug that blocks that issue.

There have been some tiny API changes in LLVM, and cmpxchg changed its
return type. The i1 part of the new return type is only interesting when
using the new weak cmpxchg, which we don't do.