Users who build `core` for the sole purpose of enabling `panic_immediate_abort` might expect
"`panic_immediate_abort` is now a real panic strategy" to mean that setting `panic =
"immediate-abort"` in `Cargo.toml` or `-Cpanic=immediate-abort` in `RUSTFLAGS` to be sufficient for
migration. But this is not the case, `core` still needs to be built for those changes to take
effect.
See https://github.com/rust-lang/rust/issues/146974 for additional context.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#145943 (stdlib docs: document lifetime extension for `format_args!`'s arguments)
- rust-lang/rust#147243 (cmse: disallow `impl Trait` in `cmse-nonsecure-entry` return types)
- rust-lang/rust#147402 ([rustdoc] Don't serialize & deserialize data that doesn't go OTW)
- rust-lang/rust#147418 (Fix target list of `link_section`)
- rust-lang/rust#147429 (Print tip for human error format in runtest)
- rust-lang/rust#147441 (Fix comments error for Provenance impls)
- rust-lang/rust#147442 (c-variadic: fix thir-print for `...` without a pattern)
r? `@ghost`
`@rustbot` modify labels: rollup
stdlib docs: document lifetime extension for `format_args!`'s arguments
Since rust-lang/rust#140748 is stable and rust-lang/rust#92698 is closed, the section about `format_args!`'s argument lifetime limitation is outdated. I've updated it to point to the Reference docs, which will specify lifetime extension rules for builtin macros once rust-lang/reference#1980 or equivalent is merged.
I've also taken the liberty of updating one of the doctests to assign the result of `format_args!` to a variable, both to provide an example and because I think it reads a little better.
r? `@m-ou-se`
Improve the advice given by panic_immediate_abort
Now that https://github.com/rust-lang/rust/pull/147338 is merged, users should consider using the Cargo support for immediate-aborting panics.
Make `fmt::Write` a diagnostic item
I'm working on an enhancement to [`clippy::format_push_string`](https://rust-lang.github.io/rust-clippy/master/index.html#format_push_string), which would suggest an autofix to replace `push_str`/`+=` with `write!`. But that could require importing `std::fmt::Write`, and so I need this diagnostic item to check if it's already in scope.
The reason I called it `FmtWrite` and not just `Write` is that there's already an `IoWrite` defined.
formatting_options: fix alternate docs 0b/0o mixup
The descriptions of the alternate forms of Octal and Binary were swapped in the doc comment for FormattingOptions::alternate().
Introduce CoerceShared lang item and trait, and basic Reborrow tests
Part of rust-lang/rust#145612: This introduces the `CoerceShared` trait which is the `Reborrow` equivalent of a `&mut T` -> `&T` coercion. The trait has a `Target` GAT which makes this (currently) unique in the `core/src/marker.rs`; I'm not sure if this can be considered problematic. Maybe this is not the way such things should be done at the marker trait level? Or maybe it is fine.
Improtantly, this PR introduces a battery of basic `Reborrow` and `CoerceShared` tests. These test the very basics of the feature; custom marker types intended to have exclusive semantics (`Custom<'a>(PhantomData<&'a mut ()>)`), custom exclusive reference wrappers, and standard library exclusive reference wrappers (`Pin<&mut T>` and `Option<&mut T>`). None of these of course work since the implementation for `Reborrow` and `CoerceShared` is entirely missing, but this is the first step towards making these work.
Future PRs will introduce more tests, such as "recursive" reborrowing (ie. reborrowing structs that contain multiple reborrowable fields) and checks around the lifetime semantics of reborrowing ie. that a reborrow produces a new type with the same lifetime as the original.
Add doc for `NonZero*` const creation
I ran into trouble using `NonZero*` values because I didn’t see any clear way to create them at compile time. At first I ended up using `NonZero*::new_unchecked` a lot, until I realized that `Option::unwrap` and `Option::expect` are `const` and can be used in a `const` context. With that, you can create non-zero values at compile time safely, without touching `unsafe`. This wasn’t obvious to me and my peers who’ve been using Rust for a while, so I thought adding a note to the docs would make it easier for others to discover.
If this should be worded differently or placed in another location, we can do that. I just want to make this more obvious.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146556 (Fix duration_since panic on unix when std is built with integer overflow checks)
- rust-lang/rust#146679 (Clarify Display for error should not include source)
- rust-lang/rust#146753 (Improve the pretty print of UnstableFeature clause)
- rust-lang/rust#146894 (Improve derive suggestion of const param)
- rust-lang/rust#146950 (core: simplify `CStr::default()`)
- rust-lang/rust#146958 (Fix infinite recursion in Path::eq with String)
- rust-lang/rust#146971 (fix ICE in writeback due to bound regions)
r? `@ghost`
`@rustbot` modify labels: rollup
Make missed precondition-free float intrinsics safe
So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse.
Extra follow-up to rust-lang/rust#146683.
r? ```@RalfJung``` who reviewed the previous one
These don't appear to be used anywhere outside of the standard locations, at least.
