operate on `HirId` in `hir::Pat::each_binding`, and consequences of that

Changing the `each_binding` utility method to take the `HirId` of a
binding pattern rather than its `NodeId` seems like a modest first step
in support of the `HirId`ification initiative #50928. (The inspiration
for choosing this in particular came from the present author's previous
work on diagnostics issued during liveness analysis, which is the most
greatly affected module in this change.)

Auto merge of #51118 - nrc:update, r=oli-obk

Update RLS, Rustfmt, and Cargo

r? @Mark-Simulacrum

Should fix broken rustfmt and RLS builds - Cargo update is needed for compatibility with RLS

Auto merge of #50724 - zackmdavis:applicability_rush, r=Manishearth

add suggestion applicabilities to librustc and libsyntax

A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means).

r? @Manishearth
cc @killercup @estebank

Auto merge of #50612 - Zoxc:thin-slice, r=michaelwoerister

Make &Slice a thin pointer

Split out from https://github.com/rust-lang/rust/pull/50395

r? @michaelwoerister

Update RLS, Rustfmt, and Cargo

Auto merge of #50892 - davidtwco:issue-50004, r=alexcrichton

Added rustdoc documentation to compiler docs.

Fixes #50004.

r? @alexcrichton
(since you reviewed the last PR about compiler docs)

Auto merge of #48309 - mark-i-m:anon_param_lint, r=nikomatsakis

Make anon params lint warn-by-default

This is intended as a followup on anonymous parameters deprecation.

Cross-posting from #41686:

> After having read a bit more of the discussion that I can find, I propose a more aggressive deprecation strategy:
> - We make the lint warn-by-default as soon as possible
> - We make anon parameters a hard error at the epoch boundary

cc @matklad @est31 @aturon

Auto merge of #51062 - mati865:cargo_update, r=alexcrichton

Update cargo

There are few nice fixes waiting already.

Make anon params lint warn-by-default

Auto merge of #51108 - simartin:issue_51022_follow-up, r=estebank

Address comments in pull request #51084.

This is a follow-up to https://github.com/rust-lang/rust/pull/51084, that's already been integrated into mainline.

Auto merge of #51078 - GuillaumeGomez:stabilize-formatter, r=SimonSapin

Stabilize Formatter alignment

Fixes #27726.

cc @SimonSapin

Add fields to Slice

Add assertions for TyS and TypeVariants sizes

Make &Slice a thin pointer

Address comments in pull request #51084.

Auto merge of #51105 - uuttff8:master, r=GuillaumeGomez

lib.rs don't beautiful

Stabilize Formatter alignment

Auto merge of #51101 - 11Takanori:fix-typo, r=frewsxcv

Fix typo in macro_parser.rs

innacurate -> inaccurate

Auto merge of #51084 - simartin:issue_51022, r=estebank

Issue #51022: Improve E0131 message when lifetimes are involved.

Fixes #51022

lib.rs don't beautiful

Auto merge of #51090 - kennytm:tidy-check-missing-tracking-issue, r=alexcrichton

Ensure every unstable language feature has a tracking issue.

Filled in the missing numbers:

* `abi_ptx` → #38788
* `generators` → #43122
* `global_allocator` → #27389

Reused existing tracking issues because they were decomposed from a larger feature

* `*_target_feature` → #44839 (reusing the old `target_feature` number)
* `proc_macros_*` → #38356 (reusing the to-be-stabilized `proc_macros` number)

Filed new issues

* `exhaustive_patterns` → #51085
* `pattern_parentheses` → #51087
* `wasm_custom_section` and `wasm_import_module` → #51088

Ensure every unstable feature has a tracking issue.

Auto merge of #51075 - estebank:and_the_case_of_the_confusable_float_exponent, r=eddyb

Check for confusable Unicode chars in float literal exponent

Fixing tests for #49989. Resolves #49746.

Auto merge of #51066 - est31:master, r=sfackler

Point to the current box syntax tracking issue

The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.

r? @aidanhs

innacurate -> inaccurate

Issue #51022: Improve E0131 message when lifetimes are involved.

Update cargo

Auto merge of #51094 - Mark-Simulacrum:rollup, r=Mark-Simulacrum

Rollup of 3 pull requests

Successful merges:

 - #51049 (Fix behaviour of divergence in while loop conditions)
 - #51057 (make ui tests robust with respect to NLL)
 - #51092 ([master] Release notes for 1.26.1)

Failed merges:

Fix test

Point to the current box syntax tracking issue

The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.

Rollup merge of #51092 - Mark-Simulacrum:release-notes-master, r=Mark-Simulacrum

[master] Release notes for 1.26.1

None

Rollup merge of #51057 - pnkfelix:issue-51025-make-ui-tests-robust-wrt-nll, r=nikomatsakis

make ui tests robust with respect to NLL

This PR revises the `ui` tests that I could quickly identify that:
 1. previously had successful compilations under non-lexical lifetimes (NLL) because they assumed lexical lifetimes, but
 2. such assumption of lexical lifetimes was actually not necessarily part of the spirit of the original issue/bug we want to witness.

In many cases, this is simply a matter of adding a use of a borrow so that it gets extended long enough to observe a conflict.

(In some cases the revision was more subtle, such as adding a destructor, or revising the order of declaration of some variables.)

----

With these test revisions in place, I subsequently updated the expected stderr output under the NLL compiletest mode. So now we should get even more testing of NLL than we were before.

Fix #51025

Rollup merge of #51049 - varkor:break-while-condition, r=nikomatsakis

Fix behaviour of divergence in while loop conditions

This fixes `'a: while break 'a {};` being treated as diverging, by tracking break expressions in the same way as in `loop` expressions.

Fixes #50856.

r? @nikomatsakis

Copy release notes from stable branch to master

Auto merge of #51072 - petrochenkov:ifield, r=eddyb

Use `Ident`s for fields in HIR

Continuation of https://github.com/rust-lang/rust/pull/49718, part of https://github.com/rust-lang/rust/issues/49300

Auto merge of #51052 - nikomatsakis:obsolete-arrow, r=petrochenkov

restore emplacement syntax (obsolete)

Fix https://github.com/rust-lang/rust/issues/50832

r? @petrochenkov

Add `Ident::as_str` helper

Auto merge of #51082 - kennytm:rollup, r=kennytm

Rollup of 11 pull requests

Successful merges:

 - #50987 (Underline multiple suggested replacements in the same line)
 - #51014 (Add documentation about env! second argument)
 - #51034 (Remove unused lowering field and method)
 - #51047 (Use AllFacts from polonius-engine)
 - #51048 (Add more missing examples for Formatter)
 - #51056 (Mention and use `Once::new` instead of `ONCE_INIT`)
 - #51059 (What does an expression look like, that consists only of special characters?)
 - #51065 (Update nomicon link in transmute docs)
 - #51067 (Add inner links in documentation)
 - #51070 (Fail typecheck if we encounter a bogus break)
 - #51073 (Rename TokenStream::empty to TokenStream::new)

Failed merges:

Use `Ident`s for fields in HIR

Rollup merge of #51073 - dtolnay:empty, r=alexcrichton

Rename TokenStream::empty to TokenStream::new

There is no precedent for the `empty` name -- we do not have `Vec::empty` or `HashMap::empty` etc.

I would propose landing this but reflecting it in a non-breaking release of proc-macro2 that provides both `new` and a deprecated `empty` constructor.

Tracking issue: #38356

r? @alexcrichton

Rollup merge of #51070 - est31:fix_break_const_ice, r=estebank

Fail typecheck if we encounter a bogus break

Lone breaks outside of loops create errors in the
loop check pass but as they are not fatal,
compilation continues.

MIR building code assumes all HIR break statements
to point to valid locations and fires ICEs if this
assumption is violated. In normal compilation,
this causes no issues, as code apparently prevents
MIR from being built if errors are present.

However, before that, typecheck runs and with it
MIR const eval. Here we operate differently
from normal compilation: it doesn't check for any
errors except for type checker ones and then
directly builds the MIR.

This constellation causes an ICE-on-error if
bogus break statements are being put into array
length expressions.

This commit fixes this ICE by letting typecheck
fail if bogus break statements are encountered.
This way, MIR const eval fails cleanly with a
type check error.

Fixes #50576
Fixes #50581

Rollup merge of #51067 - mcarton:patch-1, r=steveklabnik

Add inner links in documentation

From [this SO question](https://stackoverflow.com/q/50518757/2733851) it looks like this page isn't really clear.
I personally do think this page is quite clear, the only think I could think of was adding some references.

Rollup merge of #51065 - mbrubeck:docs, r=rkruppe

Update nomicon link in transmute docs

The list of "invalid primitive values" has moved to a different URL within the Rustonomicon.

Rollup merge of #51059 - oberien:patch-1, r=nikomatsakis

What does an expression look like, that consists only of special characters?

I had a lot of fun creating this together with @CryZe

Rollup merge of #51056 - tbu-:pr_once_new, r=dtolnay

Mention and use `Once::new` instead of `ONCE_INIT`

Rollup merge of #51048 - GuillaumeGomez:formatter-examples, r=QuietMisdreavus

Add more missing examples for Formatter

r? @QuietMisdreavus

Rollup merge of #51047 - spastorino:use_polonius_engine_facts, r=nikomatsakis

Use AllFacts from polonius-engine

Rollup merge of #51034 - oli-obk:lowering, r=pnkfelix

Remove unused lowering field and method

r? @nikomatsakis

So while trying to understand lowering better, I found out that there's something related to creating definitions. Analyzing that further, I realized that it is entirely dead code.

The `parent_def` field was only ever used for setting and resetting the field itself. The field was never read anywhere else and thus its value was entirely unused.

Maybe the `unused_field` lint should detect when the only use of a field is the field being read without using the read value other than writing back to the field?

The diff is best viewed without whitespace changes getting in the way: https://github.com/rust-lang/rust/pull/51034/files?w=1

Rollup merge of #51014 - GuillaumeGomez:env_docs, r=QuietMisdreavus

Add documentation about env! second argument

Fixes #48044.

r? @QuietMisdreavus

Rollup merge of #50987 - estebank:underline-multiple-suggestions, r=petrochencov

Underline multiple suggested replacements in the same line

<img width="685" alt="screen shot 2018-05-22 at 21 06 48" src="https://user-images.githubusercontent.com/1606434/40403051-174f3180-5e04-11e8-86b6-261630c5ff80.png">

Follow up to #50943.

Fix #50977.

Auto merge of #51041 - alexcrichton:better-unwind, r=nikomatsakis

std: Ensure OOM is classified as `nounwind`

OOM can't unwind today, and historically it's been optimized as if it can't
unwind. This accidentally regressed with recent changes to the OOM handler, so
this commit adds in a codegen test to assert that everything gets optimized away
after the OOM function is approrpiately classified as nounwind

Closes #50925

Auto merge of #50364 - LukasKalbertodt:improve-duration-debug-impl, r=KodrAus

Improve `Debug` impl of `time::Duration`

Hi there!

For a long time now, I was getting annoyed by the derived `Debug` impl of `Duration`. Usually, I use `Duration` to either do quick'n'dirty benchmarking or measuring the time of some operation in general. The output of the derived Debug impl is hard to parse for humans: is { secs: 0, nanos: 968360102 } or { secs: 0, nanos 98507324 } longer?

So after running into the annoyance several times (sometimes building my own function to print the Duration properly), I decided to tackle this. Now the output looks like this:

```
Duration::new(1, 0)                 => 1s
Duration::new(1, 1)                 => 1.000000001s
Duration::new(1, 300)               => 1.0000003s
Duration::new(1, 4000)              => 1.000004s
Duration::new(1, 600000)            => 1.0006s
Duration::new(1, 7000000)           => 1.007s
Duration::new(0, 0)                 => 0ns
Duration::new(0, 1)                 => 1ns
Duration::new(0, 300)               => 300ns
Duration::new(0, 4001)              => 4.001µs
Duration::new(0, 600300)            => 600.3µs
Duration::new(0, 7000000)           => 7ms
```

Note that I implemented the formatting manually and didn't use floats. No information is "lost" when printing. So `Duration::new(123_456_789_000, 900_000_001)` prints as `123456789000.900000001s`.

~~This is not yet finished~~, but I wanted to open the PR now already in order to get some feedback (maybe everyone likes the derived impl).

### Still ToDo:

- [x] Respect precision ~~and width~~ parameter of the formatter (see [this comment](https://github.com/rust-lang/rust/pull/50364#issuecomment-386107107))

### Alternatives/Decisions

- Should large durations displayed in minutes, hours, days, ...? For now, I decided not to because the current formatting is close the how a `Duration` is stored. From this new `Debug` output, you can still easily see what the values of `secs` and `nanos` are. A formatting like `3h 27m 12s 9ms` might be more appropriate for a `Display` impl?
- Should this rather be a `Display` impl and should `Debug` be derived? Maybe this formatting is too fancy for `Debug`? In my opinion it's not and, as already mentioned, from the current format one can still very easily determine the values for `secs` and `nanos`.
- Whitespace between the number and the unit?

### Notes for reviewers

- ~~The combined diff sucks. Rather review both commits individually.~~
- ~~In the unit test, I am building my own type implementing `fmt::Write` to test the output. Maybe there is already something like that which I can use?~~
- My `Debug` impl block is marked as `#[stable(...)]`... but that's fine since the derived Debug impl was stable already, right?

---

~~Apart from the main change, I moved all `time` unit tests into the `tests` directory. All other `libcore` tests are there, so I guess it was simply an oversight. Prior to this change, the `time` tests weren't run, so I guess this is kind of a bug fix. If my `Debug` impl is rejected, I can of course just send the fix as PR.~~ (this was already merged in #50466)

in which we check for confusable Unicodepoints in float literal exponent

The `FatalError.raise()` might seem unmotivated (in most places in
the compiler, `err.emit()` suffices), but it's actually used to
maintain behavior (viz., stop lexing, don't emit potentially spurious
errors looking for the next token after the bad Unicodepoint in the
exponent): the previous revision's `self.err_span_` ultimately calls
`Handler::emit`, which aborts if the `Handler`'s continue_after_error
flag is set, which seems to typically be true during lexing (see
`phase_1_parse_input` and and how `CompileController::basic` has
`continue_parse_after_error: false` in librustc_driver).

Also, let's avoid apostrophes in error messages (the present author
would argue that users expect a reassuringly detached, formal,
above-it-all tone from a Serious tool like a compiler), and use an
RLS-friendly structured suggestion.

Resolves #49746.

Auto merge of #51035 - oli-obk:unsupported_crate_type, r=eddyb

Don't ICE if crate has no valid crate types left

fixes #50993

Rename TokenStream::empty to TokenStream::new

There is no precedent for the `empty` name -- we do not have
`Vec::empty` or `HashMap::empty` etc.

Fail typecheck if we encounter a bogus break

Lone breaks outside of loops create errors in the
loop check pass but as they are not fatal,
compilation continues.

MIR building code assumes all HIR break statements
to point to valid locations and fires ICEs if this
assumption is violated. In normal compilation,
this causes no issues, as code apparently prevents
MIR from being built if errors are present.

However, before that, typecheck runs and with it
MIR const eval. Here we operate differently
from normal compilation: it doesn't check for any
errors except for type checker ones and then
directly builds the MIR.

This constellation causes an ICE-on-error if
bogus break statements are being put into array
length expressions.

This commit fixes this ICE by letting typecheck
fail if bogus break statements are encountered.
This way, MIR const eval fails cleanly with a
type check error.

Fixes #50576
Fixes #50581

Auto merge of #50070 - toidiu:ak-2093-outlives, r=nikomatsakis

2093 infer outlives requirements

Tracking issue:  #44493
RFC: https://github.com/rust-lang/rfcs/pull/2093

- [x] add `rustc_attrs` flag
- [x] use `RequirePredicates` type
- [x]  handle explicit predicates on `dyn` Trait
- [x] handle explicit predicates on projections
- [x] more tests
- [x]  remove `unused`, `dead_code` and etc..
- [x]  documentation

Auto merge of #51033 - coryshrmn:master, r=dtolnay

stabilize RangeBounds collections_range #30877

The FCP for #30877 closed last month, with the decision to:
1. move from `collections::range::RangeArgument` to `ops::RangeBounds`, and
2. rename `start()` and `end()` to `start_bounds()` and `end_bounds()`.

Simon Sapin already moved it to `ops::RangeBounds` in #49163.

I renamed the functions, and removed the old `collections::range::RangeArgument` alias.

This is my first Rust PR, please let me know if I can improve anything. This passes all tests for me, except the `clippy` tool (which uses `RangeArgument::start()`).

I considered deprecating `start()` and `end()` instead of removing them, but the contribution guidelines indicate we can break `clippy` temporarily. I thought it was best to remove the functions, since we're worried about name collisions with `Range::start` and `end`.

Closes #30877.

Add inner links in documentation

From [this SO question](https://stackoverflow.com/q/50518757/2733851) it looks like this page isn't really clear.
I personally do think this page is quite clear, the only think I could think of was adding some references.

Update nomicon link in transmute docs

The list of "invalid primitive values" has moved to a different URL
within the Rustonomicon.

--bless the tests

Add a test for returning inside a while loop

Fix behaviour of divergence in while loop conditions

This fixes `'a: while break 'a {};` being treated as diverging, by tracking break expressions in the same way as in `loop` expressions.

Don't use a char that's already used within the expr

Call it

What does an expression look like, that consists only of special characters?

Auto merge of #50967 - oli-obk:miri_api_refactor, r=eddyb

Miri api refactor

r? @eddyb

cc @Zoxc

based on https://github.com/rust-lang/rust/pull/50916

Implement outlives requirements inference for dyn and projections.
Add tests, documentation and attr for feature.

Adjust test for 32 bit targets

rust-lang/rust#51025: improve test robustness so that they work under NLL too.

Sanity abort `to_bits` if used on zsts

Auto merge of #51051 - nikomatsakis:turbofish-impl-trait-method, r=eddyb

prohibit turbofish in `impl Trait` methods

Fix #50950

pacify the mercilous tidy

Update comment

Auto merge of #50998 - bobtwinkles:nll_facts_invalidate_followup, r=nikomatsakis

NLL facts invalidate followup

Refactors to share code with the rest of borrow-check.

r? @nikomatsakis

Auto merge of #50986 - estebank:main-start-span, r=nikomatsakis

Tweak `main` type arguments and where clause spans

Tweak the spans for error when finding type arguments or where clauses
in main and start functions.

Auto merge of #50879 - petrochenkov:lintconv, r=nikomatsakis

Fix naming conventions for new lints

We actually have an RFC from Oct 2014 specifying naming conventions for lints that is still relevant - https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md#lints.
Unfortunately, human memory doesn't work for such prolonged periods of time, so a number of recently added edition-related lints don't follow the conventions.
This PR fixes names for those lints.

Unstable lints, simply renamed:
- `unused_lifetime` -> `unused_lifetimes`
- `absolute_path_not_starting_with_crate` -> `absolute_paths_not_starting_with_crate`
- `unnecessary_extern_crate` -> `unnecessary_extern_crates`

New lints stabilized in the last couple of releases, registered as renamed (old names still work with a warning):
- `single_use_lifetime` -> `single_use_lifetimes`
- `elided_lifetime_in_path` -> `elided_lifetimes_in_paths`
- `bare_trait_object` -> `bare_trait_objects`
- `unstable_name_collision` -> `unstable_name_collisions`
- `unused_doc_comment` -> `unused_doc_comments`

NOT changed, too old to rename:
- `const_err` -> `const_errors`
- `unused_allocation` -> `unused_allocations`

NOT changed, deprecation lints, no need to rename, they are going to be removed anyway:
- `invalid_type_param_default` -> `invalid_type_param_defaults`
- `missing_fragment_specifier` -> `missing_fragment_specifiers`
- `tyvar_behind_raw_pointer` -> `tyvars_behind_raw_pointer`
- `illegal_floating_point_literal_pattern` -> `illegal_floating_point_literal_patterns`

Fix naming conventions for new lints

Auto merge of #50937 - nikomatsakis:chalkify-engine-2, r=scalexm

implement the chalk-engine traits

Preliminary implementation for the Chalk traits in rustc. Lots of `panic!()` placeholders to be filled in later.

This is currently blocked on us landing https://github.com/rust-lang-nursery/chalk/pull/131  in chalk and issuing a new release, which should occur later today.

r? @scalexm
cc @leodasvacas

Use AllFacts from polonius-engine

restore emplacement syntax (obsolete)

prohibit turbofish in `impl Trait` methods

Auto merge of #50984 - cramertj:unpin-changes, r=aturon

Unpin changes

r? @aturon

cc @withoutboats, @RalfJung, @pythonesque, #49150

Add more missing examples for Formatter

Update issue-50993.rs

std: Ensure OOM is classified as `nounwind`

OOM can't unwind today, and historically it's been optimized as if it can't
unwind. This accidentally regressed with recent changes to the OOM handler, so
this commit adds in a codegen test to assert that everything gets optimized away
after the OOM function is approrpiately classified as nounwind

Closes #50925

Revert "Ensure llvm doesn't trigger an assert for crazy transmutes"

This reverts commit 776c632e2a9a044fd134321a9d561e28994ff3ff.

Rename `amt` variables to `shift`

Use in-band-lifetimes instead of unused explicit lifetimes

Prefer `to_value_with_len` over manual expanison of it

Remove dead code

Add missing newlines

`tcx.lift_to_global` > `tcx.global_tcx().lift`

Wrongly named a closure `clamp` when it was doing truncation

Sanity check the `bits` argument to the `from_bits` function

Remove `ty_to_primitive`

Properly check defined bits range

Reuse `to_bits` instead of badly reinventing it

Only defined bits are relevant

Don't ICE on horrible transmutes in pattern constants