Rollup of 12 pull requests #78328
Closed
Rollup of 12 pull requests #78328
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
#77147 simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. To support the behavior of StaticMutex, we move part of the mutex implementation into libstd.
the commit avoid an alignement issue in Mutex implementation
This deconfuses the comparison of floats, that currently mixed ranges and non-ranges.
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.
…tion The optimization introduces additional uses of the discriminant operand, but does not ensure that it is still valid to evaluate it or that it still evaluates to the same value. Evaluate it once at original position, and store the result in a new temporary.
This issue was accidentally fixed recently, probably by #70743
Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 , #73670 (comment) I'm not sure if I need to add a feature gate for this flag?
revise Hermit's mutex interface to support the behaviour of StaticMutex #77147 simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. To support the new behavior of StaticMutex, we move part of the mutex implementation into libstd. The interface to the OS changed. Consequently, I removed a few functions, which aren't longer needed.
Simplify query proc-macros The query code generation is split between proc-macros and regular macros in `rustc_middle::ty::query`. This PR removes unused capabilities of the proc-macros, and tend to use regular macros for the logic.
Do not ICE with TraitPredicates containing [type error] Fix #77919.
…r, r=RalfJung
Fix const core::panic!(non_literal_str).
Invocations of `core::panic!(x)` where `x` is not a string literal expand to `panic!("{}", x)`, which is not understood by the const panic logic right now. This adds `panic_str` as a lang item, and modifies the const eval implementation to hook into this item as well.
This fixes the issue mentioned here: #51999 (comment)
r? `@RalfJung`
`@rustbot` modify labels: +A-const-eval
Cleanup constant matching in exhaustiveness checking This supercedes #77390. I made the `Opaque` constructor work. I have opened two issues #78071 and #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 #78071
…=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"
```
…oli-obk Introduce a temporary for discriminant value in MatchBranchSimplification The optimization introduces additional uses of the discriminant operand, but does not ensure that it is still valid to evaluate it or that it still evaluates to the same value. Evaluate it once at original position, and store the result in a new temporary. Follow up on #78151. The optimization remains disabled by default. Closes #78239.
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/gh.neting.cc-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 #48919 </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
const_evaluatable_checked: deal with unused nodes + div r? @oli-obk
Bump backtrace-rs to enable Mach-O support on iOS. Related to rust-lang/backtrace-rs#378. Fixes backtraces on iOS that were missing in Rust v1.47.0 after switching to gimli because it only enabled Mach-O support on macOS.
TyCtxt: generate single impl block with `slice_interners` macro Reduces the work needed to check overlapping impls a bit.
|
📌 Commit fd038b5 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit fd038b5 with merge 879890c6723514a44a222486f4bbdb6a10739df4... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
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:
#[cfg(panic = '...')]#74754 (Add#[cfg(panic = '...')])compiler_builtinsto 0.1.36 #78209 (Updatecompiler_builtinsto 0.1.36)slice_internersmacro #78318 (TyCtxt: generate single impl block withslice_internersmacro)Failed merges:
r? @ghost