Fix backtraces with `-C panic=abort` on linux; emit unwind tables by default
The linux backtrace unwinder relies on unwind tables to work properly, and generating and printing a backtrace is done by for example the default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see history below) so that backtraces work.
Closes https://github.com/rust-lang/rust/issues/81902 which is **regression-from-stable-to-stable**
Closes https://github.com/rust-lang/rust/issues/94815
### History
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C panic=abort` (see https://github.com/rust-lang/rust/pull/45031 and https://github.com/rust-lang/rust/issues/81902#issuecomment-3046487084).
In 1.45 a workaround in the form of `-C force-unwind-tables=yes` was added (see https://github.com/rust-lang/rust/pull/69984).
`-C panic=abort` was added in [Rust 1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable) and the motivation was binary size and compile time. But given how confusing that behavior has turned out to be, it is better to make binary size optimization opt-in with `-C force-unwind-tables=no` rather than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other tricks that can be used that has a higher impact.
# Release Note Entry Draft:
## Compatibility Notes
* [Fix backtraces with `-C panic=abort` on Linux by generating unwind tables by default](https://github.com/rust-lang/rust/pull/143613). Build with `-C force-unwind-tables=no` to keep omitting unwind tables.
try-job: aarch64-apple
try-job: armhf-gnu
try-job: aarch64-msvc-1
Introduce debuginfo to statements in MIR
The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix rust-lang/rust#128081.
I don't modify Stable MIR, as I don't think we need debug information when using it.
This PR represents the debug information for the dead reference statement via `#dbg_value`. For example, `let _foo_b = &foo.b` becomes `#dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26)`. You can see this here: https://rust.godbolt.org/z/d43js6adv.
The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR.
The current rules for dropping debug information in this PR are:
- If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now.
- All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M.
I doesn't drop debuginfos in `MatchBranchSimplification`, because LLVM also pick one branch for it.
If the `LocalRef` is `LocalRef::Place`, we can refer to it directly,
because the local of place is an indirect pointer.
Such a statement is `_1 = &(_2.1)`.
If the `LocalRef` is `LocalRef::Operand`,
the `OperandRef` should provide the pointer of the reference.
Such a statement is `_1 = &((*_2).1)`.
But there is a special case that hasn't been handled, scalar pairs like `(&[i32; 16], i32)`.
Extending `#[rustc_force_inline]` to be applicable to inherent methods
`#[rustc_force_inline]` is an internal-only attribute similar to `#[inline(always)]` but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved).
`#[rustc_force_inline]` is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions).
Since its initial implementation, `#[rustc_force_inline]` could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined.
r? `@saethlin`
The linux backtrace unwinder relies on unwind tables to work properly,
and generating and printing a backtrace is done by for example the
default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see
history below) so that backtraces work.
History
=======
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in
Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C
panic=abort` (see 24cc38e3b0).
In 1.45 (see cda994633e) a workaround in the form
of `-C force-unwind-tables=yes` was added.
`-C panic=abort` was added in [Rust
1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable)
and the motivation was binary size and compile time. But given how
confusing that behavior has turned out to be, it is better to make
binary size optimization opt-in with `-C force-unwind-tables=no` rather
than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other
tricks that can be used that has a higher impact.
Forbid `//@ compile-flags: -Cincremental=` in tests
Tests should not try to manually enable incremental compilation with `-Cincremental`, because that typically results in stray directories being created in the repository root.
Also, if the incremental directory is not cleared, there is a risk of interference between successive runs of the same test.
Instead, use the `//@ incremental` directive, which instructs compiletest to handle the details of passing `-Cincremental` with a fresh directory.
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a `match` expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like `match a { b:` would confuse the parser and think everything after `match` *must* be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
mbe: Implement `unsafe` attribute rules
This implements `unsafe attr` rules for declarative `macro_rules!` attributes, as specified in [RFC 3697](https://github.com/rust-lang/rfcs/pull/3697).
An invocation of an attribute that uses an `unsafe attr` rule requires the `unsafe(attr(...))` syntax.
An invocation of an attribute that uses an ordinary `attr` rule must *not* use the `unsafe(attr(...))` syntax.
`unsafe` is only supported on an `attr` rule, not any other kind of `macro_rules!` rule.
Tracking issue for `macro_rules!` attributes: https://github.com/rust-lang/rust/issues/143547
Support `#[rustc_align_static]` inside `thread_local!`
Tracking issue: rust-lang/rust#146177
```rust
thread_local! {
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = const { 0 };
}
```
This increases the amount of recursion the macro performs (once per attribute in addition to the previous once per item), making it easier to hit the recursion limit. I’ve added workarounds to limit the impact in the case of long doc comments, but this still needs a crater run just in case.
r? libs
``@rustbot`` label A-attributes A-macros A-thread-locals F-static_align T-libs
Turn ProjectionElem::Subtype into CastKind::Subtype
I noticed that drop elaboration can't, in general, handle `ProjectionElem::SubType`. It creates a disjoint move path that overlaps with other move paths. (`Subslice` does too, and I'm working on a different PR to make that special case less fragile.) If its skipped and treated as the same move path as its parent then `MovePath.place` has multiple possible projections. (It would probably make sense to remove all `Subtype` projections for the canonical place but it doesn't make sense to have this special case for a problem that doesn't actually occur in real MIR.)
The only reason this doesn't break is that `Subtype` is always the sole projection of the local its applied to. For the same reason, it works fine as a `CastKind` so I figured that makes more sense than documenting and validating this hidden invariant.
cc rust-lang/rust#112651, rust-lang/rust#133258
r? Icnr (bc you've been the main person dealing with `Subtype` it looks like)
Tests should not try to manually enable incremental compilation with
`-Cincremental`, because that typically results in stray directories being
created in the repository root.
Instead, use the `//@ incremental` directive, which instructs compiletest to
handle the details of passing `-Cincremental` with a fresh directory.
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146593 (Allow specifying multiple bounds for same associated item, except in trait objects)
- rust-lang/rust#147177 ([DebugInfo] Fix MSVC tuple child creation)
- rust-lang/rust#147195 (iter repeat: add tests for new count and last behavior)
- rust-lang/rust#147202 (Swap order of `resolve_coroutine_interiors` and `handle_opaque_type_uses`)
- rust-lang/rust#147204 (Refactor ArrayWindows to use a slice)
- rust-lang/rust#147219 (Add proper error handling for closure in impl)
- rust-lang/rust#147226 (include `outer_inclusive_binder` of pattern types)
- rust-lang/rust#147230 (Fix typo in 'unfulfilled_lint_expectation' to plural)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't create a top-level `true` directory when running UI tests
The funny thing about writing `-Cincremental=true` is that it *does* enable incremental compilation ... using an incremental compilation dir of `./true`.
And for UI tests, that ends up creating a `true` directory in the repository root, which is annoying.
Fortunately, compiletest has an existing `//@ incremental` directive that takes care of creating an empty incremental directory, and passing it to `-Cincremental`.
---
I have manually checked that reverting rust-lang/rust#146649 still causes the updated test to fail.
Remove `no-remap-src-base` from tests
Previously in the `//`-compiletest-directive times, `no-remap-src-base` was implemented as a special `no-*` directive parsing. In the migration from `//` -> `//`@`,` the `// no-remap-src-base` directive was lost, most likely because it had no effect -- the default is not remapping `src-base`.
So remove occurrences of `no-remap-src-base`, as these are not valid directives.
r? `@Zalathar` (since we discussed this on discord, or compiler)
Fix autodiff empty ret regression
closes https://github.com/rust-lang/rust/issues/147144
The two gsoc summer projects caused a bit of churn, which was to be expected, especially since we don't run autodiff in CI yet.
This adds a void return testcase that we should have had anyway, and fixes the regression.
r? `@Zalathar` (Just guessing since I've seen you in a few LLVM PRs and Oli is probably still busy. Feel free to reroll!)
Previously in the `//`-compiletest-directive times, this was implemented
as a special `no-*` directive parsing. In the migration from `//` ->
`//@`, the `// no-remap-src-base` directive was lost, most likely
because it had no effect -- the default is not remapping `src-base`.
So remove occurrences of `no-remap-src-base`, as these are not valid
directives.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#143069 (Add fast-path for accessing the current thread id)
- rust-lang/rust#146518 (Improve the documentation around `ZERO_AR_DATE`)
- rust-lang/rust#146596 (Add a dummy codegen backend)
- rust-lang/rust#146617 (Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics)
- rust-lang/rust#146635 (cg_llvm: Stop using `as_c_char_ptr` for coverage-related bindings)
- rust-lang/rust#147184 (Fix the bevy implied bounds hack for the next solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix the bevy implied bounds hack for the next solver
The diff is trivial, of course, and basically what you already suggested. Mostly dug around a bunch to learn. I hope this is roughly what you had in mind.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/236.
r? `@lcnr`
Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics
Fixes https://github.com/rust-lang/rust/issues/132024.
``@rustbot`` label A-diagnostics T-compiler
