Stabilize `PanicInfo::message()` and `PanicMessage`
Resolves#66745
This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html).
Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker):
```rust
#![no_std]
#![no_main]
extern crate libc;
#[no_mangle]
extern "C" fn main() -> libc::c_int {
panic!("I just panic every time");
}
#[panic_handler]
fn my_panic(panic_info: &core::panic::PanicInfo) -> ! {
use arrayvec::ArrayString;
use core::fmt::Write;
let message = panic_info.message();
let location = panic_info.location().unwrap();
let mut debug_msg = ArrayString::<1024>::new();
let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'");
if debug_msg.try_push_str("\0").is_ok() {
unsafe {
libc::puts(debug_msg.as_ptr() as *const _);
}
}
unsafe { libc::exit(libc::EXIT_FAILURE) }
}
```
```
$ cargo +stage1 run --release
panicked with 'I just panic every time' at 'src/main.rs:8:5'
```
- [x] FCP: https://github.com/rust-lang/rust/issues/66745#issuecomment-2198143725
r? libs-api
In 126578 we ended up with more binary size increases than expected.
This change attempts to avoid inlining large things into small things, to avoid that kind of increase, in cases when top-down inlining will still be able to do that inlining later.
Cleanup bootstrap check-cfg
This PR cleanup many custom `check-cfg` in bootstrap that have been accumulated over the years.
As well as updating some outdated comments.
small correction to fmt::Pointer impl
~~The `addr` method does not require `T: Sized`, and is preferred for use over `expose_provenance`.~~
`expose_provenance` does not require `T: Sized`.
Print `TypeId` as a `u128` for `Debug`
Since <https://github.com/rust-lang/rust/pull/121358>, `TypeId` is represented as a `(u64, u64)`. This also made the debug implementation a lot larger, which is especially apparent with pretty formatting.
Change this to convert the inner value back to a `u128` and then print as a tuple struct to make this less noisy.
Current:
TypeId { t: (1403077013027291752, 4518903163082958039) }
TypeId {
t: (
1403077013027291752,
4518903163082958039,
),
}
New:
TypeId(25882202575019293479932656973818029271)
TypeId(
25882202575019293479932656973818029271,
)
Small fixme in core now that split_first has no codegen issues
https://github.com/rust-lang/rust/issues/109328#issuecomment-1677366881
BTW, I have a crate implementing exactly this kind of an iterator: https://github.com/GrigorenkoPV/head-tail-iter and I was wondering if it would be worthwhile to try and make an ACP for it to get it included in std (or maybe itertools). My only doubt is that it kinda incentives writing O(n^2) algorithms and is not the hard to replace with a `while let` loop (just as in this PR).
Rollup of 9 pull requests
Successful merges:
- #123237 (Various rustc_codegen_ssa cleanups)
- #126960 (Improve error message in tidy)
- #127002 (Implement `x perf` as a separate tool)
- #127081 (Add a run-make test that LLD is not being used by default on the x64 beta/stable channel)
- #127106 (Improve unsafe extern blocks diagnostics)
- #127110 (Fix a error suggestion for E0121 when using placeholder _ as return types on function signature.)
- #127114 (fix: prefer `(*p).clone` to `p.clone` if the `p` is a raw pointer)
- #127118 (Show `used attribute`'s kind for user when find it isn't applied to a `static` variable.)
- #127122 (Remove uneccessary condition in `div_ceil`)
r? `@ghost`
`@rustbot` modify labels: rollup
Since <https://github.com/rust-lang/rust/pull/121358>, `TypeId` is
represented as a `(u64, u64)`. This also made the debug implementation a
lot larger, which is especially apparent with pretty formatting.
Make this less noisy by converting the inner value back to a `u128` then
printing as a tuple struct.
Current:
TypeId { t: (1403077013027291752, 4518903163082958039) }
TypeId {
t: (
1403077013027291752,
4518903163082958039,
),
}
New:
TypeId(25882202575019293479932656973818029271)
TypeId(
25882202575019293479932656973818029271,
)
Remove uneccessary condition in `div_ceil`
Previously, `div_ceil` for unsigned integers had a `rhs > 0` for rounding. That condition however is always fulfilled, since `rhs == 0` would mean a division by zero earlier.
Implement new effects desugaring
cc `@rust-lang/project-const-traits.` Will write down notes once I have finished.
* [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>`
* [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>`
* [ ] add types and traits to minicore test
* [ ] update rustc-dev-guide
Fixes#119717Fixes#123664Fixes#124857Fixes#126148
docs: say "includes" instead of "does include"
Provides more visual difference between the negative ("does not include") and the positive ("includes"). Both phrases have the same meaning.
std: separate TLS key creation from TLS access
Currently, `std` performs an atomic load to get the OS key on every access to `StaticKey` even when the key is already known. This PR thus replaces `StaticKey` with the platform-specific `get` and `set` function and a new `LazyKey` type that acts as a `LazyLock<Key>`, allowing the reuse of the retreived key for multiple accesses.
Related to #110897.
core: avoid `extern type`s in formatting infrastructure
```@RalfJung``` [said](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Use.20of.20.60extern.20type.60.20in.20formatting.20machinery/near/446552837):
>How attached are y'all to using `extern type` in the formatting machinery?
Seems like this was introduced a [long time ago](34ef8f5441). However, it's also [not really compatible with Stacked Borrows](https://github.com/rust-lang/unsafe-code-guidelines/issues/256), and only works currently because we effectively treat references-to-extern-type almost like raw pointers in Stacked Borrows -- which of course is unsound, it's not how LLVM works. I was planning to make Miri emit a warning when this happens to avoid cases like [this](https://github.com/rust-lang/rust/issues/126814#issuecomment-2183816373) where people use extern type specifically to silence Miri without realizing what happens. but with the formatting machinery using extern type, this warning would just show up everywhere...
>
> The "proper" way to do this in Stacked Borrows is to use raw pointers (or `NonNull`).
This PR does just that.
r? ```@RalfJung```
Remove `__rust_force_expr`.
This was added (with a different name) to improve an error message. It is no longer needed -- removing it changes the error message, but overall I think the new message is no worse:
- the mention of `#` in the first line is a little worse,
- but the extra context makes it very clear what the problem is, perhaps even clearer than the old message,
- and the removal of the note about the `expr` fragment (an internal detail of `__rust_force_expr`) is an improvement.
Overall I think the error is quite clear and still far better than the old message that prompted #61933, which didn't even mention patterns.
The motivation for this is #124141, which will cause pasted metavariables to be tokenized and reparsed instead of the AST node being cached. This change in behaviour occasionally has a non-zero perf cost, and `__rust_force_expr` causes the tokenize/reparse step to occur twice. Removing `__rust_force_expr` greatly reduces the extra overhead for the `deep-vector` benchmark.
r? ```@oli-obk```
Add more constants, functions, and tests for `f16` and `f128`
This adds everything that was in some way blocked on const eval, since https://github.com/rust-lang/rust/pull/126429 landed. There is a lot of `cfg(bootstrap)` since that is a fairly recent change.
`f128` tests are disabled on everything except x86_64 and Linux aarch64, which are two platforms I know have "good" support for these types - meaning basic math symbols are available and LLVM doesn't hit selection crashes. `f16` tests are enabled on almost everything except for known LLVM crashes. Doctests are only enabled on x86_64.
Tracking issue: https://github.com/rust-lang/rust/issues/116909
fix Drop items getting leaked in Filter::next_chunk
The optimization only makes sense for non-drop elements anyway. Use the default implementation for items that are Drop instead.
It also simplifies the implementation.
fixes#126872
tracking issue #98326
The optimization only makes sense for non-drop elements anyway.
Use the default implementation for items that are Drop instead.
It also simplifies the implementation.
