Optimize proc macro bridge
This optimizes the proc macro bridge code for a win of 0.7% instruction counts on the diesel-check benchmark (non-incr, full). These wins are small, but hopefully not limited to just the diesel benchmark; the code is also not seriously impacted by the changes here.
Don't panic when failing to initialize incremental directory.
This removes a panic when rustc fails to initialize the incremental directory. This can commonly happen on various filesystems that don't support locking (often various network filesystems). Panics can be confusing and scary, and there are already plenty of issues reporting this.
This has been panicking since 1.22 due to I think #44502 which was a major rework of how things work. Previously, things were simpler and the [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.21.0/src/librustc_incremental/persist/load.rs#L43-L65) function would emit an error and then continue on without panicking. With 1.22, [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.22.0/src/librustc_incremental/persist/load.rs#L44) was changed so that it assumes it can load the data without errors. Today, the problem is that it calls [`prepare_session_directory`](fbf1b1a719/compiler/rustc_interface/src/passes.rs (L175-L179)) and then immediately calls `garbage_collect_session_directories` which will panic since the session is `IncrCompSession::NotInitialized`.
The solution here is to have `prepare_session_directory` return an error that must be handled so that compilation stops if it fails.
Some other options:
* Ignore directory lock failures.
* Print a warning on directory lock failure, but otherwise continue with incremental enabled.
* Print a warning on directory lock failure, and disable incremental.
* Provide a different locking mechanism.
Cargo ignores lock errors if locking is not supported, so that would be a precedent for the first option. These options would require quite a bit more changes, but I'm happy to entertain any of them, as I think they all have valid justifications.
There is more discussion on the many issues where this is reported: #49773, #59224, #66513, #76251. I'm not sure if this can be considered closing any of those, though, since I think there is some value in discussing if there is a way to avoid the error altogether. But I think it would make sense to at least close all but one to consolidate them.
copy_from_slice generally falls back to memcpy/memmove, which is much more expensive
than we need to write a single element in.
This saves 0.26% instructions on the diesel benchmark.
A bit more polish on const eval errors
This PR adds a bit more polish to the const eval errors:
- a slight improvement to the PME messages from #85633: I mentioned there that the erroneous item's paths were dependent on the environment, and could be displayed fully qualified or not. This can obscure the items when they come from a dependency. This PR uses the pretty-printing code ensuring the items' paths are not trimmed.
- whenever there are generics involved in an item where const evaluation errors out, the error message now displays the instance and its const arguments, so that we can see which instantiated item and compile-time values lead to the error.
So we get this slight improvement for our beloved `stdarch` example, on nightly:
```
error[E0080]: evaluation of constant value failed
--> ./stdarch/crates/core_arch/src/macros.rs:8:9
|
8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', /rustc/9111b8ae9793f18179a1336417618fc07a9cac85/library/core/src/../../stdarch/crates/core_arch/src/macros.rs:8:9
|
```
to this PR's:
```
error[E0080]: evaluation of `core::core_arch::macros::ValidateConstImm::<51_i32, 0_i32, 15_i32>::VALID` failed
--> ./stdarch/crates/core_arch/src/macros.rs:8:9
|
8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9
|
```
with this PR.
Of course this is an idea from Oli, so maybe r? `@oli-obk` if they have the time.
const-eval: disallow unwinding across functions that `!fn_can_unwind()`
Following https://github.com/rust-lang/miri/pull/1776#discussion_r633074343, so r? `@RalfJung`
This PR turns `unwind` in `StackPopCleanup::Goto` into a new enum `StackPopUnwind`, with a `NotAllowed` variant to indicate that unwinding is not allowed. This variant is chosen based on `rustc_middle::ty::layout::fn_can_unwind()` in `eval_fn_call()` when pushing the frame. A check is added in `unwind_to_block()` to report UB if unwinding happens across a `StackPopUnwind::NotAllowed` frame.
Tested with Miri `HEAD` with [minor changes](https://github.com/rust-lang/miri/compare/HEAD..9cf3c7f0d86325a586fbcbf2acdc9232b861f1d8) and the rust-lang/miri#1776 branch with [these changes](d866c1c52f..626638fbfe).
Add #[track_caller] to panic_any
Report the panic location from the user code.
```rust
use std::panic;
use std::panic::panic_any;
fn main() {
panic::set_hook(Box::new(|panic_info| {
if let Some(location) = panic_info.location() {
println!(
"panic occurred in file '{}' at line {}",
location.file(),
location.line(),
);
} else {
println!("panic occurred but can't get location information...");
}
}));
panic_any(42);
}
````
Before:
`panic occurred in file '/rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904/library/std/src/panic.rs' at line 59`
After:
`panic occurred in file 'src/main.rs' at line 17`
Fix incorrect suggestions for E0605
Fixes#84598. Here is a simplified version of the problem presented in issue #84598:
```Rust
#![allow(unused_variables)]
#![allow(dead_code)]
trait T { fn t(&self) -> i32; }
unsafe fn foo(t: *mut dyn T) {
(t as &dyn T).t();
}
fn main() {}
```
The current output is:
```
error[E0605]: non-primitive cast: `*mut (dyn T + 'static)` as `&dyn T`
--> src/main.rs:7:5
|
7 | (t as &dyn T).t();
| ^^^^^^^^^^^^^ invalid cast
|
help: borrow the value for the cast to be valid
|
7 | (&t as &dyn T).t();
| ^
```
This is incorrect, though: The cast will _not_ be valid when writing `&t` instead of `t`:
```
error[E0277]: the trait bound `*mut (dyn T + 'static): T` is not satisfied
--> t4.rs:7:6
|
7 | (&t as &dyn T).t();
| ^^ the trait `T` is not implemented for `*mut (dyn T + 'static)`
|
= note: required for the cast to the object type `dyn T`
```
The correct suggestion is `&*t`, which I have implemented in this pull request. Of course, this suggestion will always require an unsafe block, but arguably, that's what the user really wants if they're trying to cast a pointer to a reference.
In any case, claiming that the cast will be valid after implementing the suggestion is overly optimistic, as the coercion logic doesn't seem to resolve all nested obligations, i.e. the cast may still be invalid after implementing the suggestion. I have therefore rephrased the suggestion slightly ("consider borrowing the value" instead of "borrow the value for the cast to be valid").
Additionally, I have fixed another incorrect suggestion not mentioned in #84598, which relates to casting immutable references to mutable ones:
```rust
fn main() {
let mut x = 0;
let m = &x as &mut i32;
}
```
currently leads to
```
error[E0605]: non-primitive cast: `&i32` as `&mut i32`
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^^^^^^^^^^^^^ invalid cast
|
help: borrow the value for the cast to be valid
|
3 | let m = &mut &x as &mut i32;
| ^^^^
```
which is obviously incorrect:
```
error[E0596]: cannot borrow data in a `&` reference as mutable
--> t5.rs:3:13
|
3 | let m = &mut &x as &mut i32;
| ^^^^^^^ cannot borrow as mutable
```
I've changed the suggestion to a note explaining the problem:
```
error[E0605]: non-primitive cast: `&i32` as `&mut i32`
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^^^^^^^^^^^^^ invalid cast
|
note: this reference is immutable
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^
note: trying to cast to a mutable reference type
--> t5.rs:3:19
|
3 | let m = &x as &mut i32;
| ^^^^^^^^
```
In this example, it would have been even nicer to suggest replacing `&x` with `&mut x`, but this would be much more complex because we would have to take apart the expression to be cast (currently, we only look at its type), and `&x` could be stored in a variable, where such a suggestion would not even be directly applicable:
```rust
fn main() {
let mut x = 0;
let r = &x;
let m = r as &mut i32;
}
```
My solution covers this case, too.
Sync rustc_codegen_cranelift
The main highlight this sync is the removal of several dependencies, making compilation of cg_clif itself faster. There have also been a couple of new features like `#[link_section]` now supporting different segments for Mach-O binaries (thanks `@eggyal!)` and the `imported_main` feature, which is currently unstable.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Mention workaround for floats in Iterator::{min, max}
`Iterator::{min, max}` can't be used with iterators of floats due to NaN issues. This suggests a workaround in the documentation of those functions.
Fix trait methods' toggle
A `<details>` tag wasn't closed on trait methods, which created broken DOM. I also used this occasion to only generate the toggle in case there is documentation on the method.
r? `@jsha`
Enable Vec's calloc optimization for Option<NonZero>
Someone on discord noticed that `vec![None::<NonZeroU32>; N]` wasn't getting the optimization, so here's a PR 🙃
We can certainly do this in the standard library because we know for sure this is ok, but I think it's also a necessary consequence of documented guarantees like those in https://doc.rust-lang.org/std/option/#representation and https://doc.rust-lang.org/core/num/struct.NonZeroU32.html
It feels weird to do this without adding a test, but I wasn't sure where that would belong. Is it worth adding codegen tests for these?
libunwind fix and cleanup
Fix:
1. "system-llvm-libunwind" now only skip build-script for linux target
2. workaround from https://github.com/rust-lang/rust/pull/65972 is not needed, upstream fix it in 68c50708d1 ( LLVM 11 )
3. remove code for MSCV and Apple in `compile()`, as they are not used
4. fix https://github.com/rust-lang/rust/issues/69222 , compile c files and cpp files in different config
5. fix conditional compilation for musl target.
6. fix that x86_64-fortanix-unknown-sgx don't link libunwind built in build-script into rlib
Add inline attr to CString::into_inner so it can optimize out NonNull checks
It seems that currently if you convert any of the standard library's container to a pointer and then to a NonNull pointer, all will optimize out the NULL check except `CString`(https://godbolt.org/z/YPKW9G5xn),
because for some reason `CString::into_inner` isn't inlined even though it's a private function that should compile into a simple `mov` instruction.
Adding a simple `#[inline]` attribute solves this, code example:
```rust
use std::ffi::CString;
use std::ptr::NonNull;
pub fn cstring_nonull(mut n: CString) -> NonNull<i8> {
NonNull::new(CString::into_raw(n)).unwrap()
}
```
assembly before:
```asm
__ZN3wat14cstring_nonull17h371c755bcad76294E:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
.cfi_def_cfa_register %rbp
callq __ZN3std3ffi5c_str7CString10into_inner17h28ece07b276e2878E
testq %rax, %rax
je LBB0_2
popq %rbp
retq
LBB0_2:
leaq l___unnamed_1(%rip), %rdi
leaq l___unnamed_2(%rip), %rdx
movl $43, %esi
callq __ZN4core9panicking5panic17h92a83fa9085a8f73E
.cfi_endproc
.section __TEXT,__const
l___unnamed_1:
.ascii "called `Option::unwrap()` on a `None` value"
l___unnamed_3:
.ascii "wat.rs"
.section __DATA,__const
.p2align 3
l___unnamed_2:
.quad l___unnamed_3
.asciz "\006\000\000\000\000\000\000\000\006\000\000\000(\000\000"
```
Assembly after:
```asm
__ZN3wat14cstring_nonull17h9645eb9341fb25d7E:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq %rsp, %rbp
.cfi_def_cfa_register %rbp
movq %rdi, %rax
popq %rbp
retq
.cfi_endproc
```
(Related discussion on zulip: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/NonNull.20From.3CBox.3CT.3E.3E)
