Rename
* Error::iter_chain() -> Error::chain()
* ErrorIter -> Chain

Removed
* Error::iter_sources()

according to
rust-lang#58520

Rationale:

   1. Such iterators are helpful. They should better be stabilized sooner
      than later.
   2. self should be included. It is easy to .skip(1) it.
      Not including self is harmful because it is harder to add self
      to the iterator than to remove it.
   3. The chosen name should be telling and reflect the fact that self is
      included. `.chain()` was chosen because the iterator iterates over
      the chain of errors that is somehow included in self.
   4. The resulting iterator is named `Chain` because the `error::Chain`
      is what we want to have.

…static error

…tatic error

The `Context` argument is currently smuggled through TLS for
async-generated futures. The current infrastructure is closure-based,
and results in an extra 6 stack frames when .awaiting an async-generated
future!

```
  12: foo::async_b::{{closure}}
             at src/main.rs:10
  13: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43
  14: std::future::set_task_context
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79
  15: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43
  16: std::future::poll_with_tls_context::{{closure}}
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121
  17: std::future::get_task_context
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111
  18: std::future::poll_with_tls_context
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121
  19: foo::async_a::{{closure}}
             at src/main.rs:6
```

While the long (medium?) term solution is to remove the use of TLS
entirely, we can improve things a bit in the meantime. In particular,
this commit does 2 things:

1. `get_task_context` has been inlined into `poll_with_tls_context`,
    removing 2 frames (16 and 17 above).
2. `set_task_context` now returns a guard type that resets the TLS
    rather than taking a closure, removing 2 frames (13 and 14 above).

We can also remove frame 18 by removing `poll_with_tls_context` in favor
of a `get_task_context` function which returns a guard, but that
requires adjusting the code generated for .await, so I've left that off
for now.

rename Error::iter_chain() and remove Error::iter_sources()

~~Rename~~
* ~~Error::iter_chain() -> Error::chained()~~
* ~~Error::iter_sources() -> Error::ancestors()~~
* ~~ErrorIter -> Chained and Ancestors~~

according to
rust-lang#58520 (comment)

Tracker:
rust-lang#58520

Edit:

Rename
* Error::iter_chain() -> Error::chained()
* ErrorIter -> Chain

So, it seems, that even Path::ancestors() includes itself. So, to avoid confusion and simplify it more, I reduced PR  rust-lang#65557 to only have `chained` and `Chain`.

Rationale:

   1. Such iterators are helpful. They should better be stabilized sooner than later.
   1. self should be included. It is easy to .skip(1) it.  Not including self is harmful because it is harder to add self to the iterator than to remove it.
   1. The chosen name should be telling and reflect the fact that self is included. `.chained()` was chosen in honor of error-chain and because the iterator iterates over the chain of errors that is somehow included in self.
   1. The resulting iterator is named `Chain` because the `error::Chain` is what we want to have.

Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering

We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per rust-lang/rfcs#2515, this needs to change to allow `impl Trait` in nested positions.  This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported.

r? @varkor

…miri, r=oli-obk

Remove cannot mutate statics in initializer of another static error

r? @oli-obk

This is just a refactoring. As the removed code itself said, it only a heuristic catching a few cases early instead of leaving it all to const eval. It's easy to work around the static check and then run into the miri-engine check.

Update mdbook.

This brings in some important updates to fix some rendering issues in the books. In particular fixing hidden lines in code blocks, and some escaping issues.  More details at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md

This also requires updating mdbook-linkcheck.

Do not ICE in `if` without `else` in `async fn`

Fix rust-lang#66387.

Make a test compatible across python versions.

Progress on rust-lang#65063

This PR allows this test to work on both python2 and python3, and it also allows `./x.py test` to fully complete on my system without python2 installed at all.

Remove some stack frames from `.async` calls

The `Context` argument is currently smuggled through TLS for
async-generated futures. The current infrastructure is closure-based,
and results in an extra 6 stack frames when .awaiting an async-generated
future!

```
  12: foo::async_b::{{closure}}
             at src/main.rs:10
  13: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43
  14: std::future::set_task_context
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79
  15: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43
  16: std::future::poll_with_tls_context::{{closure}}
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121
  17: std::future::get_task_context
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111
  18: std::future::poll_with_tls_context
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121
  19: foo::async_a::{{closure}}
             at src/main.rs:6
```

While the long (medium?) term solution is to remove the use of TLS
entirely, we can improve things a bit in the meantime. In particular,
this commit does 2 things:

1. `get_task_context` has been inlined into `poll_with_tls_context`,
    removing 2 frames (16 and 17 above).
2. `set_task_context` now returns a guard type that resets the TLS
    rather than taking a closure, removing 2 frames (13 and 14 above).

We can also remove frame 18 by removing `poll_with_tls_context` in favor
of a `get_task_context` function which returns a guard, but that
requires adjusting the code generated for .await, so I've left that off
for now.

miri: helper methods for max values of machine's usize/isize

We recently wanted this in Miri.

r? @oli-obk

…msg, r=estebank

Link to tracking issue in HIR const-check error code description

This is a follow up to rust-lang#66170 that addresses [this comment](rust-lang#66170 (comment)).

As an aside, the only other error code whose description uses the phrase "tracking issue" is `E0202`. We may want to come up with standards around this, especially since error codes are now centralized and easier to keep track of (thanks @GuillaumeGomez).

r? @estebank (since they +1'ed the comment)