On nightly, dump ICE backtraces to disk
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic handler will also write the contents of the backtrace to disk. If any `delay_span_bug`s are encountered, their backtrace is also added to the file. The platform and rustc version will also be collected.
<img width="1032" alt="Screenshot 2023-03-03 at 2 13 25 PM" src="https://user-images.githubusercontent.com/1606434/222842420-8e039740-4042-4563-b31d-599677171acf.png">
The current behavior will *always* write to disk on nightly builds, regardless of whether the backtrace is printed to the terminal, unless the environment variable `RUSTC_ICE_DISK_DUMP` is set to `0`. This is a compromise and can be changed.
In `base.rs`, tweak how the CGU size interleaving works. Since #113777,
it's much more common to have multiple CGUs with identical sizes. With
the existing code these same-sized items ended up in the
opposite-to-desired order due to the stable sorting. The code now starts
with a reverse sort (like is done in `partitioning.rs`) which gives the
behaviour we want. This doesn't matter much for perf, but makes profiles
in `samply` look more like what we expect.
In `partitioning.rs`, we can use `sort_by_key` instead of
`sort_by_cached_key` because `CGU::size_estimate()` is cheap. (There is
an identical CGU sort earlier in that function that already uses
`sort_by_key`.)
Rollup of 7 pull requests
Successful merges:
- #113444 (add tests for alias bound preference)
- #113716 (Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.)
- #113754 (Simplify native_libs query)
- #113765 (Make it clearer that edition functions are `>=`, not `==`)
- #113774 (Improve error message when closing bracket interpreted as formatting fill character)
- #113785 (Fix invalid display of inlined re-export when both local and foreign items are inlined)
- #113803 (Fix inline_const with interpolated block)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix inline_const with interpolated block
Interpolation already worked when we had a `const $block` that wasn't a statement expr:
```
fn foo() {
let _ = const $block;
}
```
But it was failing when the const block was in statement expr position:
```
fn foo() {
const $block;
}
```
... because of a bug in a check for const items. This fixes that.
---
cc https://github.com/rust-lang/rust/pull/112953#issuecomment-1631354481, though I don't think this requires an FCP since it's already supported in exprs and seems to me to be fully a parser bug.
Make it clearer that edition functions are `>=`, not `==`
r? `@Nilstrieb`
We could also perhaps derive `Ord` on `Edition` and use comparison operators.
Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.
**When `no_builtins` is applied at the crate level, we should add the `no-builtins` attribute to each function to ensure it takes effect in LTO.**
This is also the reason why no_builtins does not take effect in LTO as mentioned in #35540.
Now, `#![no_builtins]` should be similar to `-fno-builtin` in clang/gcc, see https://clang.godbolt.org/z/z4j6Wsod5.
Next, we should make `#![no_builtins]` participate in LTO again. That makes sense, as LTO also takes into consideration function-level instruction optimizations, such as the MachineOutliner. More importantly, when a user writes a large `#![no_builtins]` crate, they would like this crate to participate in LTO as well.
We should also add a function-level no_builtins attribute to allow users to have more control over it. This is similar to Clang's `__attribute__((no_builtin))` feature, see https://clang.godbolt.org/z/Wod6KK6eq. Before implementing this feature, maybe we should discuss whether to support more fine-grained control, such as `__attribute__((no_builtin("memcpy")))`.
Related discussions:
- #109821
- #35540
Next (a separate pull request?):
- [ ] Revert #35637
- [ ] Add a function-level `no_builtin` attribute?
Encode shorthands for spans in metadata.
Spans occupy a typically large proportion of metadata.
This PR deduplicates encoded spans in order to reduce encoded length.
This ensures that rustc will not attempt to link against a cdylib as if
it is a rust dylib when an rlib for the same crate is available.
Previously rustc didn't actually check if any further formats of a
crate which has been loaded are of the same version and if they are
actually valid. This caused a cdylib to be interpreted as rust dylib as
soon as the corresponding rlib was loaded. As cdylibs don't export any
rust symbols, linking would fail if rustc decides to link against the
cdylib rather than the rlib.
Two crates depended on the previous behavior by separately compiling a
test crate as both rlib and dylib. These have been changed to capture
their original spirit to the best of my ability while still working
when rustc verifies that all crates are in sync. It is unlikely that
build systems depend on the current behavior and in any case we are
taking a lot of measures to ensure that any change to either the source
or the compilation options (including crate type) results in rustc
rejecting it as incompatible. We merely didn't do this check here for
now obsolete perf reasons.
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
Reasoning: if the stack is empty, the loop will be infinite,
so the assumption is that the stack can't be non empty. Unwrap
makes the assumption more clear (and removes an indentation level)
Consider `()` within types to be FFI-safe, and `()` to be FFI-safe as a
return type (incl. when in a transparent newtype).
Signed-off-by: David Wood <david@davidtw.co>
`()` is normally FFI-unsafe, but is FFI-safe when used as a return type.
It is also desirable that a transparent newtype for `()` is FFI-safe when
used as a return type.
In order to support this, when an type was deemed FFI-unsafe, because of
a `()` type, and was used in return type - then the type was considered
FFI-safe. However, this was the wrong approach - it didn't check that the
`()` was part of a transparent newtype! The consequence of this is that
the presence of a `()` type in a more complex return type would make it
the entire type be considered safe (as long as the `()` type was the
first that the lint found) - which is obviously incorrect.
Instead, this logic is removed, and a unit return type or a transparent
wrapper around a unit is checked for directly for functions and fn-ptrs.
Signed-off-by: David Wood <david@davidtw.co>
Better diagnostics for dlltool errors.
When dlltool fails, show the full command that was executed. In particular, llvm-dlltool is not very helpful, printing a generic usage message rather than what actually went wrong, so stdout and stderr aren't of much use when troubleshooting.
allow opaques to be defined by trait queries, again
This basically reverts #112963.
Moreover, all call-sites of `enter_canonical_trait_query` can now define opaque types, see the ui test `defined-by-user-annotation.rs`.
Fixes#113689
r? `@compiler-errors` `@oli-obk`
Instead of repeatedly merging the two smallest CGUs, we now use a
merging algorithm that aims to minimize the duplication of inlined
functions.
`exa-0.10.1` was one benchmark that saw particularly good results. The
old CGU stats:
```
INTERNALIZE
- unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined)
- placed items: 3834 (1216 root + 2618 inlined), placed size: 154552 (77219 root + 77333 inlined)
- placed/unique items ratio: 1.38, placed/unique size ratio: 1.27
- CGUs: 16, mean size: 9659.5, sizes: [11791, 11634, 11173, 10987, 10939, 10507, 9992, 9813, 9593, 9580, 9030, 8447, 7975, 7961, 7876, 7254]
```
The new CGU stats:
```
INTERNALIZE
- unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined)
- placed items: 3626 (1216 root + 2410 inlined), placed size: 147201 (77219 root + 69982 inlined)
- placed/unique items ratio: 1.31, placed/unique size ratio: 1.21
- CGUs: 16, mean size: 9200.1, sizes: [11634, 10939, 10227, 9555, 9178, 9167, 8879, 8804, 8604, 8603 (x3), 8602 (x2), 8601, 8600]
```
The difference is in the number of inlined items. There are 1558 unique
inlined items. With the old algorithm these were placed 2618 times,
resulting in 1060 duplicates. With the new algorithm these were placed
2410 times, resulting in 852 duplicates. Also, the mean CGU size dropped
from 9659.5 to 9200.1, and the CGU size distribution tightened, with the
biggest one a little smaller and the smallest ones a little bigger.
