those get handled properly in strip-hidden anyway

constraints:

- clean/inline.rs needs this map to fill in traits when inlining
- fold.rs needs this map to allow passes to fold trait items
- html/render.rs needs this map to seed the Cache.traits map of all
  known traits

The first two are the real problem, since `DocFolder` only operates on
`clean::Crate` but `clean/inline.rs` only sees the `DocContext`. The
introduction of early passes means that these two now exist at the same
time, so they need to share ownership of the map. Even better, the use
of `Crate` in a rustc thread pool means that it needs to be Sync, so it
can't use `Lrc<Lock>` to manually activate thread-safety.

`parking_lot` is reused from elsewhere in the tree to allow use of its
`ReentrantMutex`, as the relevant parts of rustdoc are still
single-threaded and this allows for easier use in that context.

We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup.  See the discussion in
rust-lang/rustup#1492 for
background on this decision.  There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed.

This patch changes dist.rs to put lldb into rustlib, following what
was done for the other LLVM tools in rust-lang#53955, and then fixes rust-lldb
to prefer that lldb, if it exists.

See issue rust-lang#48168

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>

…imulacrum

stabilize #[panic_handler]

closes rust-lang#44489

### Update(2018-09-07)

This was proposed for stabilization in rust-lang#44489 (comment) and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in rust-lang#44489 (comment)

Documentation PRs:

- Reference. rust-lang/reference#362
- Nomicon. rust-lang/nomicon#75

---

`#[panic_implementation]` was implemented recently in rust-lang#50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. rust-lang#44489) but this PR is meant to start a discussion about those issues / questions with the language team.

(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in rust-lang#43054

Some unresolved questions from rust-lang#44489:

> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".

The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.

> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?

I believe @whitequark made more progress with unwinding in no-std since their last comment in rust-lang#44489. Perhaps they can give us an update?

---

Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.

cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp

…en-trait, r=GuillaumeGomez

rustdoc: collect trait impls as an early pass

Fixes rust-lang#52545, fixes rust-lang#41480, fixes rust-lang#36922

Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to rust-lang#53002, now these items actually *exist* for rustdoc to see, but they still weren't getting collected for display.

But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for *everything* and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own `trait_impls` in addition to the existing `all_trait_implementations` calls, we can collect all these tricky trait impls without having to scan for them!

rust-lang#53576 Renaming TyAnon -> TyOpaque

Fixes rust-lang#53576

…ikomatsakis

[NLL] Remove base_place

This function was supposed to make `Box` less special. But

* I think that the consensus is that MIR borrowck is going to fully special case `Box`
* It wasn't implemented correctly, it's looking at the type of the wrong `Place`, resulting in weird behaviour:

```rust
#![feature(nll)]
type A = Box<i32>; // If this is changed to another type then this will compile.

pub fn foo(x: Box<(String, A)>) {
    let a = x.0; // This will compile if these lines are swapped
    let b = x.1;
}
```

r? @nikomatsakis

Fix incorrect outer function type parameter message

Fix rust-lang#51303.

…alexcrichton

Have rust-lldb look for the rust-enabled lldb

We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup.  See the discussion in
rust-lang/rustup#1492 for
background on this decision.  There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed.  This patch changes
rust-lldb to look in the sysroot and use the lldb found there, if any.

See issue rust-lang#48168

rustbuild: allow configuring llvm version suffix

Fixes rust-lang#53852 by allowing user to install different versions of rust to the same sysroot.

rustc_resolve: don't record uniform_paths canaries as reexports.

Fixes rust-lang#53691, fixes rust-lang#53484.

…r=alexcrichton

Stabilize 2018 edition

r? @eddyb
cc @Centril @aturon