Rollup of 10 pull requests

- Successful merges: #47862, #47877, #47896, #47912, #47947, #47958, #47978, #47996, #47999, #47892
- Failed merges:

Turn `type_id` into a constant intrinsic

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

The method `get_type_id` in `Any` is intended to support reflection. It's currently unstable in favor of using an associated constant instead. This PR makes the `type_id` intrinsic a constant intrinsic, the same as `size_of` and `align_of`, allowing `TypeId::of` to be a `const fn`, which will allow using an associated constant in `Any`.

Remove 'the this' in doc comments.

Run the `run-make` tests last, so more tests run on Windows when `make` is unavailable

ui tests: diff from old (expected) to new (actual) instead of backwards.

Previously `actual` was "old" and `expected` was "new" which resulted in `+` before `-`.
AFAIK all diff tools put `-` before `+`, which made the previous behavior *very confusing*.

r? @nikomatsakis

Clarify shared file handler behavior of File::try_clone.

Fixes https://github.com/rust-lang/rust/issues/46578.

Stabilize feature(match_beginning_vert)

With this feature stabilized, match expressions can optionally have a `|` at the beginning of each arm.

Reference PR: rust-lang-nursery/reference#231

Closes #44101

Use a range to identify SIGSEGV in stack guards

Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads.  The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below that
address, if so reporting it as a stack overflow.

Now `unix` targets report a `Range<usize>` representing the guard memory,
so it can cover arbitrary guard sizes.  Non-`unix` targets which always
return `None` for guards now do so with `Option<!>`, so they don't pay any
overhead.

For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack.  However, there's no simple way for us to know
where the guard page actually lies, so now we declare it as the whole range
of `stackaddr ± guardsize`, and any fault therein will be called a stack
overflow.  This fixes #47863.

Rollup merge of #47896 - zackmdavis:and_the_case_of_the_necessary_unnecessary_parens, r=nikomatsakis

decline to lint technically-unnecessary parens in function or method arguments inside of nested macros

In #46980 ("in which the unused-parens lint..." (14982db2)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.

We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.

It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.

This is concerning #47775.

Do not ignore lifetime bounds in Copy impls

cc #29149

r? @nikomatsakis

Fix const evaluation ICE in rustdoc

Fixes #47860.

r? @EddyB

Do not enable ThinLTO on stable, beta, or nightly builds.

Fixes #45444

Update RLS and Rustfmt

r? @alexcrichton

rustc: prefer ParamEnvAnd and LayoutCx over tuples for LayoutOf.

This PR provides `tcx.layout_of(param_env.and(ty))` as the idiomatic replacement for the existing `(tcx, param_env).layout_of(ty)` and removes fragile (coherence-wise) layout-related tuple impls.

r? @nikomatsakis

Dist builds should always be as fast as we can make them, and since
those run on CI we don't care quite as much for the build being somewhat
slower. As such, we don't automatically enable ThinLTO on builds for the
dist builders.

Generator bugfixes

r? @nikomatsakis

Fixes https://github.com/rust-lang/rust/issues/46578.

elided lifetime

Closes #45992

Hey
Having a problem with my config so decided to make a WIP PR nevertheless. Will add some more tests.

Rollup of 10 pull requests

- Successful merges: #46156, #47829, #47842, #47898, #47914, #47916, #47919, #47942, #47951, #47973
- Failed merges: #47753

copy_nonoverlapping example: Fixed typo

The comment referred to a variable using an incorrect name. (it has probably been renamed since the comment was written, or the comment was copied elsewhere - I noted the example in libcore has the `tmp` name for the temporary variable.)

Tweak presentation on lifetime trait mismatch

 - On trait/impl method discrepancy, add label pointing at trait signature.
 - Point only at method definition when referring to named lifetimes on lifetime mismatch.
 - When the sub and sup expectations are the same, tweak the output to avoid repeated spans.

Fix #30790, CC #18759.

The comment referred to a variable using an incorrect name. (it has probably been renamed since the comment was written, or the comment was copied elsewhere - I noted the example in libcore has the `tmp` name for the temporary variable.)

Rollup merge of #47951 - GuillaumeGomez:sidebar-hover, r=QuietMisdreavus Fix ugly hover in sidebar In the sidebar, the elements under `Structs`, `Enums`... have an ugly hover if they're not selected. This fixes it. r? @QuietMisdreavus

Rollup merge of #47942 - estebank:macro-spans, r=nikomatsakis Minimize weird spans involving macro context Sometimes the parser attempts to synthesize spans from within a macro context with the span for the captured argument, leading to non-sensical spans with very bad output. Given that an incorrect span is worse than a partially incomplete span, when detecting this situation return only one of the spans without merging them. Fix #32072, #47778. CC #23480.

Rollup merge of #47919 - varkor:to_degrees-precision, r=rkruppe Use constant for 180/π in to_degrees The current `f32|f64.to_degrees` implementation uses a division to calculate `180/π`, which causes a loss of precision. Using a constant is still not perfect (implementing a maximally-precise algorithm would come with a high performance cost), but improves precision with a minimal change. As per the discussion in #29944, this fixes #29944 (the costs of improving the precision further would not outweigh the gains).

Rollup merge of #47916 - vmx:patch-2, r=kennytm Fix lang items box example code The `exchange_free` lang item is gone in favour of `box_free` [1]. Some warnings are also fixed by this commit. [1]: https://github.com/rust-lang/rust/commit/ca115dd083a1fe1d2b4892c5e50e49eb83ff1f3

Rollup merge of #47914 - etaoins:improve-char-escape-in-lexer-msg, r=petrochenkov Improve char escaping in lexer messages Currently ', " and \ are escaped as \', \" and \\ respectively. This leads to confusing messages such as `error: unknown start of token: \\` when encountering a single backslash. Fix by emitting printable ASCII characters directly. This will still escape \r, \n, \t and Unicode characters. Fixes #47902

Rollup merge of #47898 - Aaron1011:static-ref-nll, r=nikomatsakis Fix ICE when assigning references to a static mut with NLL is_unsafe_place only filters out statics in the rhs, not the lhs. Since it's possible to reach that 'Place::Static', we handle statics the same way as we do locals. Fixes #47789

Rollup merge of #47842 - Manishearth:dead-code, r=nagisa Remove dead code The Clone impl makes the lint ignore the type.

Rollup merge of #47829 - estebank:break-in-for, r=cramertj Suggest removing value from `break` when invalid When attempting to use `break` with a value in a type of loop where it'd be invalid (any non-`loop`), suggest using `break` on its own. Close #34359.

Document the size of bool

Include space in suggestion `mut` in bindings

Fix #46614.

Implement extensible syscall interface for wasm

Currently it's possible to run tests with the native wasm target, but it's not possible to tell whether they pass or to capture the output, because libstd throws away stdout, stderr and the exit code. While advanced libstd features should probably require more specific targets (eg. wasm-unknown-web) I think even the unknown target should at least support basic I/O.

Any solution is constrained by these factors:
- It must not be javascript specific
- There must not be too strong coupling between libstd and the host environment (because it's an "unknown" target)
- WebAssembly does not allow "optional" imports - all imports *must* be resolved.
- WebAssembly does not support calling the host environment through any channel *other* than imports.

The best solution I could find to these constraints was to give libstd a single required import, and implement a syscall-style interface through that import. Each syscall is designed such that a no-op implementation gives the most reasonable fallback behaviour. This means that the following import table would be perfectly valid:
```javascript
imports.env = { rust_wasm_syscall: function(index, data) {} }
```

Currently I have implemented these system calls:
- Read from stdin
- Write to stdout/stderr
- Set the exit code
- Get command line arguments
- Get environment variable
- Set environment variable
- Get time

It need not be extended beyond this set if being able to run tests for this target is the only goal.

edit:
As part of this PR I had to make a further change. Previously, the rust entry point would be automatically called when the webassembly module was instantiated. This was problematic because from the javascript side it was impossible to call exported functions, access program memory or get a reference to the instance.

To solve this, ~I changed the default behaviour to not automatically call the entry point, and added a crate-level attribute to regain the old behaviour. (`#![wasm_auto_run]`)~ I disabled this behaviour when building tests.