… them opaque

This deconfuses the comparison of floats, that currently mixed ranges
and non-ranges.

This allows us to use the C++ compiler configured via
`CXX_target_triple` env vars

This allows moving a lot of run-make-fulldeps tests to just run-make
tests, and allows running those on target-only platforms

Somewhat hacky to reuse `tools.mk` like this, we should probably migrate
most of them now

This makes it consistent with std::panic!("message"), which also throws
a &str, not a String.

It now throws a &str instead of a String.

Writing any fmt::Arguments would trigger the inclusion of usize
formatting and padding code in the resulting binary, because indexing
used in fmt::write would generate code using panic_bounds_check, which
prints the index and length.

These bounds checks are not necessary, as fmt::Arguments never contains
any out-of-bounds indexes.

This change replaces them with unsafe get_unchecked, to reduce the
amount of generated code, which is especially important for embedded
targets.

Since having enabled the download-ci-llvm option,
and having rebased on top of f05b47c,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.

This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.

An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.

It checks that fmt::write by itself doesn't pull in any panicking or
or display code.

Prior to this commit, debuginfo was always generated by mapping a name
to a Place. This has the side-effect that `SimplifyLocals` cannot remove
locals that are only used for debuginfo because their other uses have
been const-propagated.

To allow these locals to be removed, we now allow debuginfo to point to
a constant value. The `ConstProp` pass detects when debuginfo points to
a local with a known constant value and replaces it with the value. This
allows the later `SimplifyLocals` pass to remove the local.

and improve a comment a bit

This issue was accidentally fixed recently, probably by rust-lang#70743

…oli-obk

[mir-opt] Allow debuginfo to be generated for a constant or a Place

Prior to this commit, debuginfo was always generated by mapping a name
to a Place. This has the side-effect that `SimplifyLocals` cannot remove
locals that are only used for debuginfo because their other uses have
been const-propagated.

To allow these locals to be removed, we now allow debuginfo to point to
a constant value. The `ConstProp` pass detects when debuginfo points to
a local with a known constant value and replaces it with the value. This
allows the later `SimplifyLocals` pass to remove the local.

…, r=Mark-Simulacrum

Unignore test for rust-lang#36710 on MUSL

This now works fine thanks to autodetected `-C link-self-contained`.

Closes rust-lang#36710

…, r=varkor

Cleanup constant matching in exhaustiveness checking

This supercedes rust-lang#77390. I made the `Opaque` constructor work.
I have opened two issues rust-lang#78071 and rust-lang#78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately.

I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior.

EDIT: I accidentally fixed rust-lang#78071

…as-str, r=Amanieu

Throw core::panic!("message") as &str instead of String.

This makes `core::panic!("message")` consistent with `std::panic!("message")`, which throws a `&str` and not a `String`.

This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String`, which includes compiler-generated panics such as the panics generated for `mem::zeroed()`.

---

Demonstration:

```rust
use std::panic;
use std::any::Any;

fn main() {
    panic::set_hook(Box::new(|panic_info| check(panic_info.payload())));

    check(&*panic::catch_unwind(|| core::panic!("core")).unwrap_err());
    check(&*panic::catch_unwind(|| std::panic!("std")).unwrap_err());
}

fn check(msg: &(dyn Any + Send)) {
    if let Some(s) = msg.downcast_ref::<String>() {
        println!("Got a String: {:?}", s);
    } else if let Some(s) = msg.downcast_ref::<&str>() {
        println!("Got a &str: {:?}", s);
    }
}
```

Before:
```
Got a String: "core"
Got a String: "core"
Got a &str: "std"
Got a &str: "std"
```

After:
```
Got a &str: "core"
Got a &str: "core"
Got a &str: "std"
Got a &str: "std"
```

…bounds-check, r=dtolnay

Avoid panic_bounds_check in fmt::write.

Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary, because indexing used in fmt::write would generate code using panic_bounds_check, which prints the index and length.

These bounds checks are not necessary, as fmt::Arguments never contains any out-of-bounds indexes.

This change replaces them with unsafe get_unchecked, to reduce the amount of generated code, which is especially important for embedded targets.

---

Demonstration of the size of and the symbols in a 'hello world' no_std binary:

<details>
<summary>Source code</summary>

```rust
#![feature(lang_items)]
#![feature(start)]
#![no_std]

use core::fmt;
use core::fmt::Write;

#[link(name = "c")]
extern "C" {
    #[allow(improper_ctypes)]
    fn write(fd: i32, s: &str) -> isize;
    fn exit(code: i32) -> !;
}

struct Stdout;

impl fmt::Write for Stdout {
    fn write_str(&mut self, s: &str) -> fmt::Result {
        unsafe { write(1, s) };
        Ok(())
    }
}

#[start]
fn main(_argc: isize, _argv: *const *const u8) -> isize {
    let _ = writeln!(Stdout, "Hello World");
    0
}

#[lang = "eh_personality"]
fn eh_personality() {}

#[panic_handler]
fn panic(_: &core::panic::PanicInfo) -> ! {
    unsafe { exit(1) };
}
```
</details>

Before:
```
   text	   data	    bss	    dec	    hex	filename
   6059	    736	      8	   6803	   1a93	before
```
```
0000000000001e00 T <T as core::any::Any>::type_id
0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT
0000000000001ce0 T core::fmt::num::imp::<impl core::fmt::Display for u64>::fmt
0000000000001ce0 T core::fmt::num::imp::<impl core::fmt::Display for usize>::fmt
0000000000001370 T core::fmt::write
0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix
0000000000001660 T core::fmt::Formatter::pad_integral
0000000000001350 T core::ops::function::FnOnce::call_once
0000000000001b80 t core::ptr::drop_in_place
0000000000001120 t core::ptr::drop_in_place
0000000000001c50 t core::iter::adapters::zip::Zip<A,B>::new
0000000000001c90 t core::iter::adapters::zip::Zip<A,B>::new
0000000000001b90 T core::panicking::panic_bounds_check
0000000000001c10 T core::panicking::panic_fmt
0000000000001130 t <&mut W as core::fmt::Write>::write_char
0000000000001200 t <&mut W as core::fmt::Write>::write_fmt
0000000000001250 t <&mut W as core::fmt::Write>::write_str
```

After:
```
   text	   data	    bss	    dec	    hex	filename
   3068	    600	      8	   3676	    e5c	after
```
```
0000000000001360 T core::fmt::write
0000000000001340 T core::ops::function::FnOnce::call_once
0000000000001120 t core::ptr::drop_in_place
0000000000001620 t core::iter::adapters::zip::Zip<A,B>::new
0000000000001660 t core::iter::adapters::zip::Zip<A,B>::new
0000000000001130 t <&mut W as core::fmt::Write>::write_char
0000000000001200 t <&mut W as core::fmt::Write>::write_fmt
0000000000001250 t <&mut W as core::fmt::Write>::write_str
```

…=Mark-Simulacrum

Sync LLVM submodule if it has been initialized

Since having enabled the download-ci-llvm option,
and having rebased on top of rust-lang#76864,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.

This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.

An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.

Update cargo

3 commits in 79b397d72c557eb6444a2ba0dc00a211a226a35a..dd83ae55c871d94f060524656abab62ec40b4c40
2020-10-15 14:41:21 +0000 to 2020-10-20 19:31:26 +0000
- Support glob patterns for package/target selection (rust-lang/cargo#8752)
- Update env_logger requirement from 0.7.0 to 0.8.1 (rust-lang/cargo#8795)
- Fix man page links inside `option` blocks. (rust-lang/cargo#8793)

Miri engine: entirely skip interning of ZST, and improve some comments

r? @oli-obk

Add regression test for rust-lang#73298

Closes rust-lang#73298.

r? @lcnr

Update `compiler_builtins` to 0.1.36

So, the libc build with cargo's `build-std` feature emits a lot of warnings like:
```
 warning: a method with this name may be added to the standard library in the future
   --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/int/udiv.rs:98:23
    |
98  |             q = n << (<$ty>::BITS - sr);
    |                       ^^^^^^^^^^^
...
268 |         udivmod_inner!(n, d, rem, u128)
    |         ------------------------------- in this macro invocation
    |
    = warning: once this method is added to the standard library, the ambiguity may cause an error or change in behavior!
    = note: for more information, see issue rust-lang#48919 <rust-lang/issues/48919>
    = help: call with fully qualified syntax `Int::BITS(...)` to keep using the current method
    = help: add `#![feature(int_bits_const)]` to the crate attributes to enable `num::<impl u128>::BITS`
    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```

(You can find the full log in https://github.com/rust-lang/libc/runs/1283695796?check_suite_focus=true for example.)

0.1.36 contains rust-lang/compiler-builtins#332 so this version should remove this warning.

cc rust-lang/libc#1942