Rollup of 10 pull requests #78232
Closed
Rollup of 10 pull requests #78232
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
…, 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
|
@bors r+ rollup=never p=5 |
|
📌 Commit 62ffb30 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 62ffb30 with merge 726888479fbd59269a576f3d5799ec5c25dcf85a... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry (looks spurious) |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 62ffb30 with merge e1e73c6dcbd5c9d1ca40d21a777b5c5aa2a5cd51... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Hm, I don't think it's spurious? |
|
yeah i guess I checked the wrong build :P handling it now |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
ccfailed: exit code: 1" regression in release build with const generics #73298)compiler_builtinsto 0.1.36 #78209 (Updatecompiler_builtinsto 0.1.36)Failed merges:
r? @ghost