core: simplify `Extend` for tuples
This is an alternative to https://github.com/rust-lang/rust/pull/137400. The current macro is incredibly complicated and introduces subtle bugs like calling the `extend_one` of the individual collections in backwards order. This PR drastically simplifies the macro by removing recursion and moving the specialization out of the macro. It also fixes the ordering issue described above (I've stolen the test of the new behaviour from https://github.com/rust-lang/rust/pull/137400). Additionally, the 1-tuple is now special-cased to allow taking advantage of the well-optimized `Extend` implementations of the individual collection.
Validate CopyForDeref and DerefTemps better and remove them from runtime MIR
(split from my WIP rust-lang/rust#145344)
This PR:
- Removes `Rvalue::CopyForDeref` and `LocalInfo::DerefTemp` from runtime MIR
- Using a new mir pass `EraseDerefTemps`
- `CopyForDeref(x)` is turned into `Use(Copy(x))`
- `DerefTemp` is turned into `Boring`
- Not sure if this part is actually necessary, it made more sense in rust-lang/rust#145344 with `DerefTemp` storing actual data that I wanted to keep from having to be kept in sync with the rest of the body in runtime MIR
- Checks in validation that `CopyForDeref` and `DerefTemp` are only used together
- Removes special handling for `CopyForDeref` from many places
- Removes `CopyForDeref` from `custom_mir` reverting rust-lang/rust#111587
- In runtime MIR simple copies can be used instead
- In post cleanup analysis MIR it was already wrong to use due to the lack of support for creating `DerefTemp` locals
- Possibly this should be its own PR?
- Adds an argument to `deref_finder` to avoid creating new `DerefTemp`s and `CopyForDeref` in runtime MIR.
- Ideally we would just avoid making intermediate derefs instead of fixing it at the end of a pass / during shim building
- Removes some usages of `deref_finder` that I found out don't actually do anything
r? oli-obk
The contract_checks compiler flag is now used to determine
if runtime contract checks should be enabled, as opposed
to the compiler intrinsic as previously.
Refactor contract HIR lowering to ensure no contract code is
executed when contract-checks are disabled.
The call to contract_checks is moved to inside the lowered fn
body, and contract closures are built conditionally, ensuring
no side-effects present in contracts occur when those are disabled.
remove `#[rustc_inherit_overflow_checks]` from `is_multiple_of`
Most likely this was just a result of copy-pasting. The attribute has no effect, because `%` always uses overflow checks.
r? `@Amanieu`
cc `@RalfJung`
Prefer to use repeat_n over repeat().take()
More from https://github.com/rust-lang/rust/pull/147464, but batch processed with `ast-grep` to find and replace.
second commit add notes for library: affaf532f9
r? ``@RalfJung``
Clarify how to remediate the panic_immediate_abort error
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.
See https://github.com/rust-lang/rust/issues/147286 and https://github.com/rust-lang/cargo/issues/16042 for the revelant tracking issues.
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.
