Make `process_obligations()` greedier.

`process_obligations()` adds new nodes, but it does not process these
new nodes until the next time it is called.

This commit changes it so that it does process these new nodes within
the same call. This change reduces the number of calls to
`process_obligations()` required to complete processing, sometimes
giving significant speed-ups.

The change required some changes to tests.
- The output of `cycle-cache-err-60010.rs` is slightly different.
- The unit tests required extra cases to handle the earlier processing
  of the added nodes. I mostly did these in the simplest possible way,
  by making the added nodes be ignored, thus giving outcomes the same as
  with the old behaviour. But I changed `success_in_grandchildren()`
  more extensively so that some obligations are completed earlier than
  they used to be.

r? @nikomatsakis

Organize intrinsics promotion checks

cc @vertexclique

supersedes #61835

r? @RalfJung

rustc: split FnAbi's into definitions/direct calls ("of_instance") and indirect calls ("of_fn_ptr").

After this PR:
* `InstanceDef::Virtual` is only used for "direct" virtual calls, and shims around those calls use `InstanceDef::ReifyShim` (i.e. for `<dyn Trait as Trait>::f as fn(_)`)
  * this could easily be done for intrinsics as well, to allow their reification, but I didn't do it
* `FnAbi::of_instance` is **always** used for declaring/defining an `fn`, and for direct calls to an `fn`
  * this is great for e.g. https://github.com/rust-lang/rust/pull/65881 (`#[track_caller]`), which can introduce the "caller location" argument into "codegen signatures" by only changing `FnAbi::of_instance`, after this PR
* `FnAbi::of_fn_ptr` is used primarily for indirect calls, i.e. to `fn` pointers
  * *not* virtual calls (which use `FnAbi::of_instance` with `InstanceDef::Virtual`)
  * there's also a couple uses where the `rustc_codegen_llvm` needs to declare (i.e. FFI-import) an LLVM function that has no Rust declaration available at all
    * at least one of them could probably be a "weak lang item" instead

As there are many steps, this PR is best reviewed commit by commit - some of which arguably should be in their own PRs, I may have gotten carried away a bit.

cc @nagisa @rkruppe @oli-obk @anp

Update cargo

11 commits in 750cb1482e4d0e74822cded7ab8b3c677ed8b041..626f0f40efd32e6b3dbade50cd53fdfaa08446ba
2019-11-23 23:06:36 +0000 to 2019-12-03 16:53:04 +0000
- Change some texts to links in README (rust-lang/cargo#7652)
- Update config and environment variable docs. (rust-lang/cargo#7650)
- Stop ignoring .rs.bk files; rustfmt hasn't generated them in years (rust-lang/cargo#7647)
- Various contributing docs updates. (rust-lang/cargo#7642)
- Stabilize profile-overrides. (rust-lang/cargo#7591)
- Update comment about ResolveVersion default version. (rust-lang/cargo#7637)
- Update tests for slight wording change in rustdoc error message. (rust-lang/cargo#7641)
- Remove dep_targets. (rust-lang/cargo#7626)
- vendor: don't use canonical path in .cargo/config (rust-lang/cargo#7629)
- Minor testsuite organization. (rust-lang/cargo#7628)
- Remove failing plugin tests. (rust-lang/cargo#7630)

Update Clippy

Fixes #66989

r? @Manishearth @Centril

update Miri

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

r? @ghost

Rollup of 7 pull requests

Successful merges:

 - #66750 (Update the `wasi` crate for `wasm32-wasi`)
 - #66878 (Move Sessions into (new) librustc_session)
 - #66903 (parse_enum_item -> parse_enum_variant)
 - #66951 (miri: add throw_machine_stop macro)
 - #66957 (Change Linker for x86_64-fortanix-unknown-sgx target to rust-lld)
 - #66960 ([const-prop] Fix ICE calculating enum discriminant)
 - #66973 (Update the minimum external LLVM to 7)

Failed merges:

r? @ghost

Update the minimum external LLVM to 7

LLVM 7 is over a year old, which should be plenty for compatibility. The
last LLVM 6 holdout was llvm-emscripten, which went away in #65501.

I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions`,
which was broken by #66522.

[const-prop] Fix ICE calculating enum discriminant

Fixes #66787

Different approach than #66857

r? @oli-obk
cc @RalfJung @EddyB

Change Linker for x86_64-fortanix-unknown-sgx target to rust-lld

Changed linker for `x86_64-fortanix-unknown-sgx` target to `rust-lld`
This change needed the RelaxELFRelocations flag to be set for it to work correctly

r? @jethrogb

miri: add throw_machine_stop macro

r? @oli-obk
This helps Miri: https://github.com/rust-lang/miri/pull/1093

parse_enum_item -> parse_enum_variant

r? @estebank

Move Sessions into (new) librustc_session

This PR moves `ParseSess` and `Session` from their current locations into a new crate, `librustc_session`.

There are several intents behind this change. librustc is a very large crate, and we want to split it up over time -- this movement removes the sizeable session module from it. It also helps allow for future movement of things not coupled to TyCtxt but coupled to Session out of the crate.

This movement allows allows for a future follow-up PR which unifies Session and ParseSess, allowing for a single source of truth for APIs interested in global options throughout the compiler; the ParseSess is already created directly as a member of Session in the current compiler (i.e., we do not first construct a ParseSess and then move it into Session later in the compilation).

This PR intentionally avoids changing numerous imports throughout the tree to new locations of the moved types; this is needless noise and can be done as needed.

In the process of moving the sessions back, the lint system received an update as well -- notably, early buffered lints are no longer ad-hoc declared as enum pairs and later associated with proper lint declarations. They are still separately handled (buffered), it is a little unclear whether this is truly necessary, but regardless is left for future PRs.

Many of the types moved back are sort of ad-hoc placed into the same crate (librustc_session) instead of creating other crates; it's unclear whether this is actually a good thing, but it seemed better than creating numerous tiny crates which served no purpose on their own.

Update the `wasi` crate for `wasm32-wasi`

This commit updates the `wasi` crate used by the standard library which
is used to implement most of the functionality of libstd on the
`wasm32-wasi` target. This update comes with a brand new crate structure
in the `wasi` crate which caused quite a few changes for the wasi target
here, but it also comes with a significant change to where the
functionality is coming from.

The WASI specification is organized into "snapshots" and a new snapshot
happened recently, so the WASI APIs themselves have changed since the
previous revision. This had only minor impact on the public facing
surface area of libstd, only changing on `u32` to a `u64` in an unstable
API. The actual source for all of these types and such, however, is now
coming from the `wasi_preview_snapshot1` module instead of the
`wasi_unstable` module like before. This means that any implementors
generating binaries will need to ensure that their embedding environment
handles the `wasi_preview_snapshot1` module.

Since it's just a type alias this isn't too difficult and once Session
is moved back we can make this be the canonical location.

This commit breaks early-lint registration, which will be fixed in the
next commit. This movement will allow essentially all crates in the compiler
tree to declare lints (though not lint passes).

This commit updates the `wasi` crate used by the standard library which
is used to implement most of the functionality of libstd on the
`wasm32-wasi` target. This update comes with a brand new crate structure
in the `wasi` crate which caused quite a few changes for the wasi target
here, but it also comes with a significant change to where the
functionality is coming from.

The WASI specification is organized into "snapshots" and a new snapshot
happened recently, so the WASI APIs themselves have changed since the
previous revision. This had only minor impact on the public facing
surface area of libstd, only changing on `u32` to a `u64` in an unstable
API. The actual source for all of these types and such, however, is now
coming from the `wasi_preview_snapshot1` module instead of the
`wasi_unstable` module like before. This means that any implementors
generating binaries will need to ensure that their embedding environment
handles the `wasi_preview_snapshot1` module.