FCP: rust-lang#60245 (comment)

Closes rust-lang#60245

This returns whether a `Place` references the same region of memory
as its base, or equivalently whether it contains a `Deref` projection.

This is helpful for analyses that must track state for locals, since an
assignment to `x` or `x.field` is fundamentally different than one to
`*x`, which may mutate any memory region.

Because of a compiler bug that adding `Self: ExactSizeIterator` makes
the compiler forget `Self::Item` is `<I as Iterator>::Item`, we remove
this specialization for now.

* Make it clear that type erasure is required, not just pointer
  indirection.
* Don't make the message specific to direct recursion.

This prevents mutual `async fn` recursion

It's a hot enough path that moving it slightly earlier gives a tiny but
easy speedup.

These links are rendered in `core::cmp` but not in `std::cmp`.

Resolves rust-lang#58402.

…, r=Mark-Simulacrum

Stabilize checked_duration_since for 1.38.0

Looks like it has already found some use in projects.

Resolves rust-lang#58402.

Rev::rposition counts from the wrong end

Introduced in rust-lang#43074.

cc @SimonSapin

…lexcrichton

Stabilize pin_into_inner in 1.39.0

FCP: rust-lang#60245 (comment)

Closes rust-lang#60245

Add a `Place::is_indirect` method to determine whether a `Place` contains a `Deref` projection

Working on rust-lang#63860 requires tracking some property about each local. This requires differentiating `Place`s like `x` and `x.field[index]` from ones like `*x` and `*x.field`, since the first two will always access the same region of memory as `x` while the latter two may access any region of memory. This functionality is duplicated in various places across the compiler. This PR adds a helper method to `Place` which determines whether that `Place` has a `Deref` projection at any point and changes some existing code to use the new method.

I've not converted `qualify_consts.rs` to use the new method, since it's not a trivial conversion and it will get replaced anyway by rust-lang#63860. There may be other potential uses besides the two I change in this PR.

r? @oli-obk

… r=nikomatsakis

Harden `param_attrs` test wrt. usage of a proc macro `#[attr]`

The `param-attrs-builtin-attrs.rs` test file uses the `#[test]` attribute which should cover this but `#[test]` isn't a proc macro attribute so we add another test to be on the safe side. This intends to address rust-lang#64010 (comment).

r? @nikomatsakis

cc @c410-f3r @petrochenkov
cc rust-lang#60406

…t-recursion, r=varkor

Check impl trait substs when checking for recursive types

closes rust-lang#64004

…ts, r=alexcrichton

Add some more tests for underscore imports

…rustc-book-1.37, r=alexcrichton

Update xLTO compatibility table in rustc book.

This is a combination known to work reliable when building Firefox on all the major platforms.

r? @alexcrichton

Refer to "`self` type" instead of "receiver type"

Fix rust-lang#42603.

…er, r=petrochenkov

Move path parsing earlier

It's a hot enough path that moving it slightly earlier gives a tiny but easy speedup.

r? @petrochenkov

…ut_uninit_integers, r=Centril

Added warning around code with reference to uninit bytes

Officially, uninitialized integers, and therefore, Rust references to them are _invalid_ (note that this may evolve into official defined behavior (_c.f._, rust-lang/unsafe-code-guidelines#71)).

However, `::std` uses references to uninitialized integers when working with the `Read::initializer` feature (rust-lang#42788), since it relies on this unstably having defined behavior with the current implementation of the compiler (IIUC).

Hence the comment to disincentivize people from using this pattern outside the standard library.

unused_parens: account for or-patterns and `&(mut x)`

Fixes rust-lang#55342.
Fixes rust-lang#64106.

cc rust-lang#54883
cc rust-lang#64111

r? @oli-obk

Fix doc links in `std::cmp` module

r? @jonas-schievink

fix a few typos in comments

…ramertj

Opaque type locations in error message for clarity.

Attempts to fix rust-lang#63167