Fixes #26636

- Successful merges: #26593, #26644, #26645
- Failed merges: 

I keep forgetting the command to do partial stage1 compile, so I think it would be helpful to add it into `make tips`.

Part of #24407.
cc @michaelsproul

This branch begins the work of unifying our type checking contexts into a single piece of state. The goal is to eventually have a single context that we can pass around instead of the fractured situation we currently have. There are still several things that must be done before beginning to make tables item local:

- [ ] move FulfillmentContext into InferCtxt
- [ ] modify SelectionContext to only take a single context argument
- [ ] remove remaining typer impls 
- [ ] remove the ClosureTyper + Typer trait
- [ ] do some renaming to make these things more applicable to their new roles

r? @nikomatsakis 

As a side note there are a couple oddities that are temporary refactors that will be quickly cleaned up in a follow-up PR.

cc @EddyB @Aatch @arielb1 @nrc

Setting append without write doesn't give you a writeable file. Showing it as an example in the docs is confusing at best ([reddit](https://www.reddit.com/r/rust/comments/3bbz8w/why_is_writing_a_file_not_working_for_me/))

Using truncate (O_TRUNC) on a read-only file is an error on POSIX systems ("unspecified"). Note however that using create (O_CREAT) with read-only flags is fine.

Related: #26103 (which IMHO is wrong; saying "append is different than write" when should simply be "append needs write". My vote is to make append imply write)

Setting append without write doesn't give you a writeable file. Showing
it as an example in the docs is confusing at best.

Using truncate on a read-only file is an error on POSIX systems (note
however that using create with read-only flags is fine).

I've attempted to lurk these into a few PRs since they're tiny, but those PR's haven't landed so here they are.

r? @steveklabnik 

This series of commits (currently rebased on https://github.com/rust-lang/rust/pull/26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.

This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.

The major components of this PR are:

* Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
* All APIs not available on Windows are now accessed through our dynamic-detection mechanism
* Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.

This commit enables executables linked against the standard library to run on
Windows XP. There are two main components of this commit:

* APIs not available on XP are shimmed to have a fallback implementation and use
  runtime detection to determine if they are available.
* Mutexes on Windows were reimplemented to use critical sections on XP where
  rwlocks are not available.

The APIs which are not available on XP are:

* SetFileInformationByHandle - this is just used by `File::truncate` and that
  function just returns an error now.
* SetThreadStackGuarantee - this is used by the stack overflow support on
  windows, but if this isn't available then it's just ignored (it seems
  non-critical).
* All condition variable APIs are missing - the shims added for these apis
  simply always panic for now. We may eventually provide a fallback
  implementation, but for now the standard library does not rely on condition
  variables for normal use.
* RWLocks, like condition variables, are missing entirely. The same story for
  condition variables is taken here. These APIs are all now panicking stubs as
  the standard library doesn't rely on RWLocks for normal use.

Currently, as an optimization, we use SRWLOCKs for the standard `sync::Mutex`
implementation on Windows, which is indeed required for normal operation of the
standard library. To allow the standard library to run on XP, this commit
reimplements mutexes on Windows to use SRWLOCK instances *if available* and
otherwise a CriticalSection is used (with some checking for recursive
locking).

With all these changes put together, a 32-bit MSVC-built executable can run on
Windows XP and print "hello world"

Closes #12842
Closes #19992
Closes #24776

This first patch starts by moving around pieces of state related to
type checking. The goal is to slowly unify the type checking state
into a single typing context. This initial patch moves the
ParameterEnvironment into the InferCtxt and moves shared tables
from Inherited and ty::ctxt into their own struct Tables. This
is the foundational work to refactoring the type checker to
enable future evolution of the language and tooling.

It turns out that the 32-bit toolchain for MSVC has many of these functions as
`static inline` functions in header files so there's not actually a symbol for
Rust to call. All of the implementations just cast floats to their 64-bit
variants and then cast back to 32-bit at the end, so the standard library now
takes this strategy.

This commit adds the i686-pc-windows-msvc triple to the compiler's repertoire of
triples to prepare for targeting 32-bit MSVC.

This commit modifies the configure script and our makefiles to support building
32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can
produce a 32-bit or 64-bit binary. The configure script was updated to export
more variables at configure time, and the makefiles were rejiggered to
selectively reexport the relevant environment variables for the applicable
targets they're going to run for.

Should have happened in 69abc12b

- Successful merges: #26565, #26584, #26596, #26603
- Failed merges: 

Should have happened in 69abc12b

These will first be deprecated in 1.2.0, not 1.1.0.

At the moment, it only mentions the fix to parallel codegen.

I was going to add more, but I have to go for a while - If this isn't reviewed when I get back, I'll remove it and resubmit it after filling in more :)

Quick poll of basically the entire core team says this is ok.

Fix #26537.

This is just a simple change to ignore KDevelop 4 (and pre-release versions of KDevelop 5) project files.

Next step towards split local/global type contexts, after #26351.
cc @rust-lang/compiler @jroesch

Now that LLVM has been updated, the only remaining roadblock to implementing
unwinding for MSVC is to fill out the runtime support in `std::rt::unwind::seh`.
This commit does precisely that, fixing up some other bits and pieces along the
way:

* The `seh` unwinding module now uses `RaiseException` to initiate a panic.
* The `rust_try.ll` file was rewritten for MSVC (as it's quite different) and is
  located at `rust_try_msvc_64.ll`, only included on MSVC builds for now.
* The personality function for all landing pads generated by LLVM is hard-wired
  to `__C_specific_handler` instead of the standard `rust_eh_personality` lang
  item. This is required to get LLVM to emit SEH unwinding information instead
  of DWARF unwinding information. This also means that on MSVC the
  `rust_eh_personality` function is entirely unused (but is defined as it's a
  lang item).

More details about how panicking works on SEH can be found in the
`rust_try_msvc_64.ll` or `seh.rs` files, but I'm always open to adding more
comments!

A key aspect of this PR is missing, however, which is that **unwinding is still
turned off by default for MSVC**. There is a [bug in llvm][llvm-bug] which
causes optimizations to inline enough landing pads that LLVM chokes. If the
compiler is optimized at `-O1` (where inlining isn't enabled) then it can
bootstrap with unwinding enabled, but when optimized at `-O2` (inlining is
enabled) then it hits a fatal LLVM error.

[llvm-bug]: https://llvm.org/bugs/show_bug.cgi?id=23884

My bad!