Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 12 pull requests #78328

Closed
wants to merge 56 commits into from
Closed

Rollup of 12 pull requests #78328

wants to merge 56 commits into from

Conversation

jonas-schievink
Copy link
Contributor

Successful merges:

Failed merges:

r? @ghost

stlankes and others added 30 commits October 11, 2020 11:53
#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
cutsoy and others added 18 commits October 23, 2020 13:47
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/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 #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.
@jonas-schievink
Copy link
Contributor Author

@bors r+ rollup=never p=12

@rustbot modify labels: rollup

@bors
Copy link
Contributor

bors commented Oct 24, 2020

📌 Commit fd038b5 has been approved by jonas-schievink

@rustbot rustbot added the rollup A PR which is a rollup label Oct 24, 2020
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 24, 2020
@bors
Copy link
Contributor

bors commented Oct 24, 2020

⌛ Testing commit fd038b5 with merge 879890c6723514a44a222486f4bbdb6a10739df4...

@bors
Copy link
Contributor

bors commented Oct 24, 2020

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 24, 2020
@jonas-schievink jonas-schievink deleted the rollup-hz7xy6k branch October 24, 2020 19:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.