Add target thumbv7a-uwp-windows-msvc

Add target spec for thumbv7a-uwp-windows-msvc, so that libraries written in Rust will have a chance to run on ARM-based devices with Windows 10.

So far I managed to create a proof-of-concept library for Universal Windows Platform apps to consume and it worked on a Windows Phone. However, building a standalone executable seemed troublesome due to `LLVM ERROR: target does not implement codeview register mapping` stuff (see also https://github.com/rust-lang/rust/issues/52659#issuecomment-408233322 ).

Steps to test:
1. Clone and build this version
```sh
git clone https://github.com/bdbai/rust.git
cd rust
python x.py build -i --target thumbv7a-uwp-windows-msvc --stage 1 src/libstd
rustup toolchain link arm-uwp-stage1 .\build\x86_64-pc-windows-msvc\stage1\
```
2. Create a new library crate
```sh
cargo new --lib arm-uwp-test
cd arm-uwp-test
```
3. Change `crate-type` in `Cargo.toml` to `staticlib`
```toml
[lib]
crate-type=["staticlib"]
```
4. Replace the following code in `src/lib.rs`
```rust
#[no_mangle]
pub extern "system" fn call_rust() -> i32 {
    2333
}
```
5. Build the crate
```sh
cargo +arm-uwp-stage1 build -v --target thumbv7a-uwp-windows-msvc
```
6. `arm-uwp-test.lib` should appear in `target\thumbv7a-uwp-windows-msvc\debug`

To consume this library:
1. Make sure Visual Studio 2017 and Windows 10 SDK (10.0.17134 or above) are installed
2. Create a new Blank App (C++/WinRT) in Visual Studio 2017 (Visual Studio 2019 cannot deploy UWP apps to Windows Phone)
3. Go to Property Pages, and then Linker->Input->Additional Dependencies, add `arm-uwp-test.lib` produced just now
4. Manually declare function prototypes in `MainPage.h`
```c++
extern "C" {
    int call_rust();
}
```
5. Replace the `ClickHandler` part in `MainPage.cpp`
```c++
myButton().Content(box_value(std::to_wstring(call_rust())));
```
6. Build and deploy this app to an ARM device running Windows 10. The app should run and show `2333` when the button is clicked.

remove broken link

Not sure why this is broken @Marwes

clarify interaction of pin drop guarantee and panics

Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/232
@Diggsey would this have helped?

Clean up logic around live locals in generator analysis

Resolves #69902. Requires #71893.

I've found it difficult to make changes in the logic around live locals in `generator/transform.rs`. It uses a custom dataflow analysis, `MaybeRequiresStorage`, that AFAICT computes whether a local is either initialized or borrowed. That analysis is using `before` effects, which we should try to avoid if possible because they are harder to reason about than ones only using the unprefixed effects. @pnkfelix has suggested removing "before" effects entirely to simplify the dataflow framework, which I might pursue someday.

This PR replaces `MaybeRequiresStorage` with a combination of the existing `MaybeBorrowedLocals` and a new `MaybeInitializedLocals`. `MaybeInitializedLocals` is just `MaybeInitializedPlaces` with a coarser resolution: it works on whole locals instead of move paths. As a result, I was able to simplify the logic in `compute_storage_conflicts` and `locals_live_across_suspend_points`.

This is not exactly equivalent to the old logic; some generators are now smaller than before. I believe this was because the old logic was too conservative, but I'm not as familiar with the constraints as the original implementers were, so I could be wrong. For example, I don't see a reason the size of the `mixed_sizes` future couldn't be 5K. It went from 7K to 6K in this PR.

r? @jonas-schievink @tmandry

Rollup of 7 pull requests

Successful merges:

 - #72055 (Intern predicates)
 - #72149 (Don't `type_of` on trait assoc ty without default)
 - #72347 (Make intra-link resolve links for both trait and impl items)
 - #72350 (Improve documentation of `slice::from_raw_parts`)
 - #72382 (Show default values for debug-assertions & debug-assertions-std)
 - #72421 (Fix anchor display when hovering impl)
 - #72425 (fix discriminant_value sign extension)

Failed merges:

r? @ghost

fix discriminant_value sign extension

Fixes a regression introduced in https://github.com/rust-lang/rust/pull/70705
r? @nikomatsakis Cc @lcnr @oli-obk

Fix anchor display when hovering impl

A little gif for the fixed behaviour:

![hover-anchor](https://user-images.githubusercontent.com/3050060/82549808-cfdf4080-9b5d-11ea-9495-2b1d90b2a791.gif)

r? @kinnison

Show default values for debug-assertions & debug-assertions-std

Improve documentation of `slice::from_raw_parts`

This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.

Providing that very pattern as a counter-example could help mitigate that.

See also: https://internals.rust-lang.org/t/pre-rfc-add-join-seq-method-to-slices-and-strs/11936/13

r? @RalfJung

Make intra-link resolve links for both trait and impl items

Closes #72340

Don't `type_of` on trait assoc ty without default

Fix #72076.

Intern predicates

Implements the first step of https://github.com/rust-lang/compiler-team/issues/285

Renames `ty::Predicate` to `ty::PredicateKind`, which is now interned.
To ease the transition, `ty::Predicate` is now a struct containing a reference
to `ty::PredicateKind`.

r? @ghost

De-abuse TyKind::Error in exhaustiveness checking

Replaces https://github.com/rust-lang/rust/pull/71074. Context: https://github.com/rust-lang/rust/issues/70866.

In order to remove the use of `TyKind::Error`, I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however, since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct, that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model.

As usual, I tried to separate commits that shuffle code around from commits that require more thought to review.

cc @varkor @Centril

This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.

Providing that very pattern as a counter-example could help mitigate that.
Co-authored-by: NRalf Jung <post@ralfj.de>

Experimentally add `ffi_const` and `ffi_pure` extern fn attributes

Add FFI function attributes corresponding to clang/gcc/... `const` and `pure`.

Rebased version of #58327 by @gnzlbg with the following changes:

- Switched back from the `c_ffi_const` and `c_ffi_pure` naming to `ffi_const` and `ffi_pure`, as I agree with https://github.com/rust-lang/rust/pull/58327#issuecomment-462718772 and this nicely aligns with `ffi_returns_twice`
- (Hopefully) took care of all of @hanna-kruppe's change requests in the original PR

r? @hanna-kruppe

Rollup of 7 pull requests

Successful merges:

 - #71854 (Make `std::char` functions and constants associated to `char`.)
 - #72111 (rustc-book: Document `-Z strip=val` option)
 - #72272 (Fix going back in history to a search result page on firefox)
 - #72296 (Suggest installing VS Build Tools in more situations)
 - #72365 (Remove unused `StableHashingContext::node_to_hir_id` method)
 - #72371 (FIX - Char documentation for unexperienced users)
 - #72397 (llvm: Expose tiny code model to users)

Failed merges:

r? @ghost

llvm: Expose tiny code model to users

This model is relevant to embedded AArch64 targets and was added to LLVM relatively recently (https://reviews.llvm.org/D49673, mid 2018), so rustc frontend didn't provide access to it with `-C code-model`. The gcc analogue is [`-mcmodel=tiny`](https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html).
(This is one of the options that are passed directly to LLVM without being interpreted by rustc.)

Follow up to https://github.com/rust-lang/rust/pull/72248.

FIX - Char documentation for unexperienced users

This is my first PR on rust and even if I've read [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests) I'm ensure everything is perfect. Sorry if I didn't follow the exact procedure.

**What it does:**
- Add an example in the char documentation

**Explanation**
Unexperienced users might not know that punctuation is `Case_Ignorable` and not `Uppercase` and `Lowercase` which mean that when checking if a string is uppercase one might be tempted to write:
```rust
my_string.chars().all(char::is_uppercase)
```

However this will return false for `"HELLO WORLD"` which is not intuitive. Since the function `is_case_ignorable` doesn't exists I believe the correct way to check is:
```rust
!my_string.chars().any(char::is_lowercase)
```

The aim of this example is to prevent unexperienced users to make an error which punctuation chars.

Remove unused `StableHashingContext::node_to_hir_id` method

cc #50928

Suggest installing VS Build Tools in more situations

When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be [impenetrable](https://pastebin.com/MRMCr7HM) to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.

This only applies when Microsoft's link tool is expected.

Fix going back in history to a search result page on firefox

This bug was actually firefox not re-running JS script when you go back in history. To trigger it on the current docs:

 * Make a search
 * Pick an element (which isn't on the same page as the current element!)
 * Go back in history

Instead of having the search results, you'll see the normal doc page. You can find a small explanation about it [here](http://web.archive.org/web/20100428053932/http://www.firefoxanswer.com/firefox/672-firefoxanswer.html).

r? @kinnison

cc @ollie27

rustc-book: Document `-Z strip=val` option

cc https://github.com/rust-lang/rust/issues/72110

Make `std::char` functions and constants associated to `char`.

First step to fix https://github.com/rust-lang/rust/issues/71763.

Dumb NRVO

This is a very simple version of an NRVO pass, which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place, we bail out. This avoids running a full "reaching definitions" dataflow analysis.

I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges.

r? @ghost

Use `T`'s discriminant type in `mem::Discriminant<T>` instead of `u64`.

fixes #70509

Adds the lang-item `discriminant_kind`.
Updates the function signature of `intrinsics::discriminant_value`.
Adds the *probably permanently unstable* trait `DiscriminantKind`.
`mem::Discriminant` should now be smaller in some cases.

r? @ghost

Update to LLVM 10

LLVM 10 is going to be branched soon, so it's a good time to start finding all those tasty new miscompiles and performance regressions ;)

Status:

 * Preparation split off into #67900.
 * Optimization regressions:
   * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed.
   * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed.
   * [x] https://reviews.llvm.org/D72169 submitted.
   * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted, but unlikely eligible for LLVM 10.
 * Compile-time regressions:
   * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch.
   * [ ] Even with the revert, there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14).
 * Assertion failures / infinite loops:
   * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135, https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch.
   * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.

Rollup of 6 pull requests

Successful merges:

 - #71863 (Suggest fixes and add error recovery for `use foo::self`)
 - #72139 (Make `fold` standalone.)
 - #72275 (Continue lowering for unsupported async generator instead of returning an error.)
 - #72361 (split_inclusive: add tracking issue number (72360))
 - #72364 (Remove unused dependencies)
 - #72366 (Adjust the zero check in `RawVec::grow`.)

Failed merges:

r? @ghost

Workaround MSYS2/chocolatey issue again

When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be impenetrable to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.

This only applies when Microsoft's link tool is expected. Not `lld-link` or other MSVC compatible linkers.