* When encountering EOF, point at the last opening brace that does not
   have the same indentation level as its close delimiter.
 * When encountering the wrong type of close delimiter, point at the
   likely correct open delimiter to give a better idea of what went
   wrong.

This is useful in debugging when and where errors are emitted in
logs.

By introducing a new map that tracks the errors reported and the
`Place`s that spawned those errors against the move out that the error
was referring to, we are able to silence duplicate errors by emitting
only the error which corresponds to the most specific `Place` (that which
other `Place`s which reported errors are prefixes of).

This generally is an improvement, however there is a case -
`liveness-move-in-while` - where the output regresses.

- Fixes rust-lang#53174

I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:

* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
  unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
  platforms.

In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!

unless `#[rustc_promotable]` is added to the function

Limit the promotion of const fns to the libstd and the `rustc_promotable` attribute

There are so many questions around promoting const fn calls... it seems saner to try to limit automatic promotion to const fns which were explicitly opted in for promotion.

I added the attribute to all public stable const fns that were already promotable (e.g. not Cell::new) in order to not cause any breakage

r? @eddyb

cc @nikomatsakis

…akis

Improve messages for un-closed delimiter errors

Fix incorrect outer function type parameter message

Fix rust-lang#51303.

rustc_resolve: only prepend CrateRoot to a non-keyword segment.

Fixes rust-lang#53770 by treating `use` paths as absolute in a finer-grained manner, specifically:
```rust
use {a, crate::b, self::c, super::d};
```
Used to be interpreted as if it were (when `uniform_paths` is not enabled):
```rust
use ::{a, crate::b, self::c, super::d};
```
With this PR, the `CrateRoot` pseudo-keyword indicating an absolute path is only inserted when the first path segment is found (if it's not a keyword), i.e. the example behaves like:
```rust
use {::a, crate::b, self::c, super::d};
```
This should (finally) make `use {path};` fully equivalent to `use path;`.

r? @petrochenkov cc @cramertj @joshtriplett @nikomatsakis

Too many errors for incorrect move in loop with NLL enabled

Fixes rust-lang#53807.

r? @nikomatsakis

rustc_codegen_llvm: don't assume offsets are always aligned.

Fixes rust-lang#53728 by taking into account not just overall type alignment and the field's alignment when determining whether a field is aligned or not ("packed"), but also the field's offset within the type.

Previously, rustc assumed that the offset was always at least as aligned as `min(struct.align, field.align)`. However, there's no real reason to have that assumption, and it obviously can't always be true after we implement `#[repr(align(N), pack(K))]`. There's also a case today where that assumption is not true, involving niche discriminants in enums:

Suppose that we have the code in rust-lang#53728:
```Rust
#[repr(u16)]
enum DeviceKind {
    Nil = 0,
}

#[repr(packed)]
struct DeviceInfo {
    endianness: u8,
    device_kind: DeviceKind,
}

struct Wrapper {
    device_info: DeviceInfo,
    data: u32
}
```

Observe the layout of `Option<Wrapper>`. It has an alignment of 4 because of the `u32`. `device_info.device_kind` is a good niche field to use, which means the enum ends up with this layout:
```
size = 8
align = 4
fields = [
    { offset=1, type=u16 } // discriminant, .<Some>.device_info.device_kind
]
```

And here we have an discriminant with alignment 2 (`u16`) but offset 1.

Allow named lifetimes in async functions.

- Fixes rust-lang#53174

Code by @eddyb; @cramertj suggested I lift it off another change so we can fix rust-lang#53174.

r? @cramertj

…rochenkov

rustc_resolve: inject `uniform_paths` canary always on Rust 2018.

**NOTE**: this PR is based on rust-lang#53988, only the second commit is new.

This PR is an attempt at future-proofing "anchored paths" by emitting the same ambiguity errors that `#![feature(uniform_paths)]` would, with slightly changed phrasing (see added UI tests).

r? @petrochenkov cc @aturon @Centril @joshtriplett

…rochenkov

Fix compiling some rustc crates to wasm

I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:

* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
  unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
  platforms.

In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!

…-clippy, r=alexcrichton

Stabilize edition 2018; also updates Clippy and RLS

Supersedes rust-lang#53999
Clippy build was failing there because crate_visibility_modifier feature was taken out of edition 2018 and clippy used it.
The clippy update enables the corresponding feature explicitly.

r? @Mark-Simulacrum

`&CStr`, not `CStr`, is the counterpart of `&str`