Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>

…n matching

…ting new ones

…ands

…selves

Use slice patterns to avoid having to skip bounds checking

…varkor

Various const eval and pattern matching ICE fixes

r? @RalfJung
cc @spastorino

This PR does not change existing behaviour anymore and just fixes a bunch of ICEs reachable from user code (sometimes even on stable via obscure union transmutes).

Add regression tests for fixed ICEs

Closes rust-lang#61747 (fixed from 1.41.0-nightly (4007d4e 2019-12-01))
Closes rust-lang#66205 (fixed from 1.41.0-nightly (4007d4e 2019-12-01))
Closes rust-lang#66270 (fixed by rust-lang#66246)
Closes rust-lang#67424 (fixed by rust-lang#67160)

Also picking a minor nit up from rust-lang#67071 with 101dd7b

r? @Centril

…=Dylan-DPC

Cleanup err codes

r? @Dylan-DPC

Add long error code explanation message for E0627

Part of rust-lang#61137.

r? @GuillaumeGomez

…schievink

remove `description` from `Error` impls in docs

Since `description` is soft-deprecated, there's no need to show it implemented in these examples.

…oli-obk

Clean up unsafety in char::encode_utf8

This originally started as an attempt to allow LLVM to optimize through
encode_utf8 to detect the try_encode_utf8 case (rust-lang#52579, rust-lang#52580), but due to a
typo my conclusion that my optimizations were successful was incorrect.

Furthermore, as far as I can tell, this optimization is probably just not
possible with LLVM today.  This [code](https://rust.godbolt.org/z/JggRj4)
compiles down to a long series of compares, notably, two identical series of
compares. That essentially means that LLVM is today unable to see that these two
ifs are identical and as such can be merged and then realize that no value of
the if condition can result in a call to `please_delete`. As such, for now, we
do not attempt to specifically optimize for that case.

…rk-Simulacrum

Use the chocolatey CDN directly to avoid the flaky API