The goal is that the compiler will pass `Result`s around rather than using abort_if_errors. To preserve behaviour we currently abort at the top level. I've removed all other aborts from the driver, but haven't touched any of the nested aborts.

This PR adds some minor error correction to the parser - if there is a missing ident, we recover and carry on. It also makes compilation more robust so that non-fatal errors (which is still most of them, unfortunately) in parsing do not cause us to abort compilation. The effect is that a program with a missing or incorrect ident can get all the way to type checking.

Also altered the format_args! syntax extension, and \#[derive(debug)], to maintain compatability.
r? @ nrc

Also got rid of some code repetition in `const_eval`

In 95d90462 output was accidentally moved
from STDERR to STDOUT.

This commit also changes the order of debug output. Previously, it was:

```
/* id 22: … */ {
  …
}
DEBUG:rustc::middle::dataflow:
```

Now, it is:

```
DEBUG:rustc::middle::dataflow: /* id 22: … */ {
  …
}
```

Register LLVM passes with the correct LLVM pass manager.

LLVM was upgraded to a new version in this commit:

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf

which was part of this pull request:

https://github.com/rust-lang/rust/issues/26025

Consider the following two lines from that commit:

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469

The purpose of these lines is to register LLVM passes. Prior to the that
commit, the passes being handled were assumed to be ModulePasses (a
specific type of LLVM pass) since they were being added to a ModulePass
manager. After that commit, both lines were refactored (presumably in an
attempt to DRY out the code), but the ModulePasses were changed to be
registered to a FunctionPass manager. This change resulted in
ModulePasses being run, but a Function object was being passed as a
parameter to the pass instead of a Module, which resulted in
segmentation faults.

In this commit, I changed relevant sections of the code to check the
type of the passes being added and register them to the appropriate pass
manager.

Closes https://github.com/rust-lang/rust/issues/31067

In 95d90462 output was accidentally moved
from STDERR to STDOUT.

This commit also changes the order of debug output. Previously, it was:

```
/* id 22: … */ {
  …
}
DEBUG:rustc::middle::dataflow:
```

Now, it is:

```
DEBUG:rustc::middle::dataflow: /* id 22: … */ {
  …
}
```

LLVM was upgraded to a new version in this commit:

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf

which was part of this pull request:

https://github.com/rust-lang/rust/issues/26025

Consider the following two lines from that commit:

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462

https://github.com/rust-lang/rust/commit/f9d4149c29e8b989fa3624993be379f380e48dcf#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469

The purpose of these lines is to register LLVM passes. Prior to the that
commit, the passes being handled were assumed to be ModulePasses (a
specific type of LLVM pass) since they were being added to a ModulePass
manager. After that commit, both lines were refactored (presumably in an
attempt to DRY out the code), but the ModulePasses were changed to be
registered to a FunctionPass manager. This change resulted in
ModulePasses being run, but a Function object was being passed as a
parameter to the pass instead of a Module, which resulted in
segmentation faults.

In this commit, I changed relevant sections of the code to check the
type of the passes being added and register them to the appropriate pass
manager.

Closes https://github.com/rust-lang/rust/issues/31067

Also remove a "finally" in the section about building for release to make it feel a bit friendlier.

The implementation changed in 33a2191d, but the comments did not change to match.

r? @alexcrichton

Version of Clang in repository is 3.9

So, error is caused by
```
./configure --enable-dist-host-only --enable-clang
```
Then, I got
```
configure: error: bad CLANG version: 3.9.0 (http://llvm.org/git/clang.git 3d5d4c39659f11dfbe8e11c857cadf5c449b559b) (http://llvm.org/git/llvm.git, need >=3.0svn
```

I fixed this issue by appending 3.9* in the if sentence.
Thanks.

The implementation changed in 33a2191d, but the comments did not change
to match.

Fixes #30705

r? @nagisa

Fixes #30705

Also remove a "finally" in the section about building for release
to make it feel a bit friendlier.

- Successful merges: #30997, #31019, #31031, #31035, #31045, #31050, #31054, #31055, #31061, #31088, #31090, #31111, #31113, #31128, #31130, #31136, #31145, #31146
- Failed merges: #30932

r? @steveklabnik

Also change the examples to make this more obvious. Fixes #31129.

E0210 explains about orphan rules and suggests using a local type as a workaround. It wasn't obvious to me that I couldn't use a type alias, so I added a note.

r? @alexcrichton

Closes #31103

r? @steveklabnik

I've been interested in the accessibility of Rustdoc's output, but never did anything about it. Today, I ran a tool, and it suggested adjusting some colors.

Here's some screen shots. Before:
![2016-01-20-114944_443x199_scrot](https://cloud.githubusercontent.com/assets/27786/12455979/d84d7ae8-bf6b-11e5-9aea-0602fb1a8cfa.png)

After:

![2016-01-20-114516_453x204_scrot](https://cloud.githubusercontent.com/assets/27786/12455841/36a55d14-bf6b-11e5-8014-239594c12e46.png)

As you can see, the link text is just a _shade_ darker.

Browsable: http://www.steveklabnik.com/rust-a11y-doc-testing/doc/std/

Closes #31048

r? @Manishearth

I tried to add an inline `span_suggestion()` to the error as well, but since generics don't have their own span it becomes too fragile/complicated to work.

r? @steveklabnik

fixes #19477

Responding to [a thread of discussion on the Rust subreddit](https://www.reddit.com/r/rust/comments/3racik/mutable_lifetimes_are_too_long_when_matching_an/),
it was identified that the presence of the Entry API is not duly
publicised. This commit aims to add some reasonable examples of
common usages of this API to the main example secion of the `HashMap`
documentation.

This is part of issue #29348.

This was fixed in passing. Adding a regression test.

Documentation of `CStr::from_ptr` suggests using `str::from_utf8(slice.to_bytes()).unwrap()`
to obtain a `&str` but `CStr` has `CStr::to_str` that does exactly that.

(First PR, be nice :)

Fix type parameter default error to mention type and trait definitions

Introduced in PR #30724, needs to mention that type parameter defaults
are legal in trait and type definitions too.

Fix type parameter default error to mention type and trait definitions

Introduced in PR #30724, needs to mention that type parameter defaults
are legal in trait and type definitions too.