Implement `Debug` for `EncodeWide`
Since `std::os::windows::ffi::EncodeWide` was reexported from `std::sys_common::wtf8::EncodeWide`, which has `#![allow(missing_debug_implementations)]` in the parent module, it did not implement `Debug`. When it was moved to `core`, a placeholder impl was added; fill it in.
This becomes insta-stable.
r? libs-api
The notation used here (e.g. "transmute `t: T` to `Option<T>`") felt
maybe a bit heavy, in the context of the library documentation, so
let's elaborate this a bit.
Also, in the `Option` docs, we talk about this being true for "the
following types `T`", but it felt this caveat might get a bit lost in
the next sentence that talks about the valid transmutations, so let's
reiterate the caveat.
While we're touching the line, we can improve:
> The only difference is the implied semantics:
This sentence was a bit awkward due to the mismatched plurality and
not identifying the difference being spoken to. We'll reword this to
make it more clear.
We'll wrap to 80, since the existing text and most of the doc comments
in these files are wrapped this way.
`is_ascii` on an empty string or slice returns true
Update the description of the [`is_ascii`](https://doc.rust-lang.org/std/primitive.str.html#method.is_ascii) functions - an empty string or slice also returns `true`.
This follows the pattern of [`all()`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.all). Clippy currently suggests to change `string.chars().all(|c| c.is_ascii())` into `string.is_ascii()`. This suggestion therefore seems fitting.
I've already questioned the behavior for this multiple times. I've always had to check the internals to conclude how it works. That's why I'm opening this PR to add it directly in the documentation.
Guard HIR lowered contracts with `contract_checks`
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. This partially addresses rust-lang/rust#139548, i.e. the bad behavior no longer happens with contract checks disabled (`-Zcontract-checks=no`).
The change is made in preparation for adding contract variable declarations - variables declared before the `requires` assertion, and accessible from both `requires` and `ensures`, but not in the function body (PR rust-lang/rust#144444). As those declarations may also have side-effects, it's good to guard them with `contract_checks` - the new lowering approach allows for this to be done easily.
Contracts tracking issue: rust-lang/rust#128044
**Known limiatations**:
- It is still possible to early return from the *function* from within a contract, e.g.
```rust
#[ensures({if x > 0 { return 0 }; |_| true})]
fn foo(x: u32) -> i32 {
42
}
```
When `foo` is called with an argument greater than 0, instead of `42`, `0` will be returned.
As this is not a regression, it is not addressed in this PR. However, it may be worth revisiting later down the line, as users may expect a form of early return from *contract specifications*, and so returning from the entire *function* could cause confusion.
- ~Contracts are still not optimised out when disabled. Currently, even when contracts are disabled, the code generated causes existing optimisations to fail, meaning even disabled contracts could impact runtime performance. This issue is blocking rust-lang/rust#136578, and has not been addressed in this PR, i.e. the `mir-opt` and `codegen` tests that fail in rust-lang/rust#136578 still fail with these new HIR lowering changes.~ Contracts should now be optimised out when disabled, however some regressions tests still need to be added to be sure that is indeed the case.
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#143191 (Stabilize `rwlock_downgrade` library feature)
- rust-lang/rust#147444 (Allow printing a fully-qualified path in `def_path_str`)
- rust-lang/rust#147527 (Update t-compiler beta nomination Zulip msg)
- rust-lang/rust#147670 (some `ErrorGuaranteed` cleanups)
- rust-lang/rust#147676 (Return spans out of `is_doc_comment` to reduce reliance on `.span()` on attributes)
- rust-lang/rust#147708 (const `mem::drop`)
- rust-lang/rust#147710 (Fix ICE when using contracts on async functions)
- rust-lang/rust#147716 (Fix some comments)
- rust-lang/rust#147718 (miri: use allocator_shim_contents codegen helper)
- rust-lang/rust#147729 (ignore boring locals when explaining why a borrow contains a point due to drop of a live local under polonius)
- rust-lang/rust#147742 (Revert unintentional whitespace changes to rustfmt-excluded file)
r? `@ghost`
`@rustbot` modify labels: rollup
const `mem::drop`
I'm putting this under the `const Destruct` feature flag since it doesn't really feel relevant to put it elsewhere… it's just an empty function body, so, it doesn't have any particular weirdness attached to it (unlike `drop_in_place`, for example).
r? wg-const-eval
prefer alias candidates for sizedness + auto trait goals
Fixesrust-lang/rust#143992
- abd07dec44437554520453f929c2b12d4eb8b11e: Reverts rust-lang/rust#144016 so that `MetaSized` bounds are checked properly, and updates all the tests accordingly, including making `tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs` fail when it shouldn't
- 90e61db9745f53d9aef21e3ebce0df19cc1389d7: Prefer alias candidates over parameter environment candidates for sizedness, auto and default traits. `tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs` passes again, but `tests/ui/generic-associated-types/issue-93262.rs` starts failing when it shouldn't
- e412062171925d0b40fdbeb5765c45087bdf0fe7: No longer require that predicates of aliases hold in well-formedness checking of the alias. `tests/ui/generic-associated-types/issue-93262.rs` passes again
Each commit updates all the tests to their new output so it should be easy enough to see what the impact of each change individually is. After all of the changes, tests that pass when they didn't before or vice versa:
- `tests/ui/extern/extern-types-size_of_val.rs`
- Previously passing, but only because of rust-lang/rust#144016, now correctly errors
- `tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs`
- Previously failing on next solver, only because rust-lang/rust#144016 only applied to the old solver, passing now with 90e61db9745f53d9aef21e3ebce0df19cc1389d7
- `tests/ui/sized-hierarchy/overflow.rs`
- Previously passing, but only because of rust-lang/rust#144016, now correctly errors
- `tests/ui/generic-associated-types/issue-92096.rs`
- Previously passing, due to e412062171925d0b40fdbeb5765c45087bdf0fe7
- Fails to prove `C::Connecting<'placeholder>: Send` which is required when proving that the generator is `Send`. This is an instance of rust-lang/rust#110338.
- `tests/ui/higher-ranked/trait-bounds/normalize-under-binder/norm-before-method-resolution-opaque-type.rs`
- Previously passing, now failing in the next solver, due to 03e0fdab6196e81b44356f42f03b6a0a224cf451
- Expected that this test now fails as ambigious, see [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/sizedness.20bounds.20in.20explicit_implied_predicates_of.20.28.23142712.29/near/526987384)
This had a crater run in https://github.com/rust-lang/rust/pull/142712#issuecomment-3050358772 alongside some other changes.
r? `@lcnr`
cc rust-lang/rust#142712 (this extracts part of that change)
Clarify that UB will occur, not can/may in GlobalAlloc docs
These doc comments start out very clear by saying the caller "must" or "has to" ensure something, but the end with some form of "otherwise undefined behavior may result" which sounds like it is implementation-defined and seems to conflict with the way the paragraph starts. Consistent phrasing makes it clearer that when the safety precondition is violated, UB is encountered.
Some of the phrasing here is a bit awkward to me, I don't think we usually say "the behavior is undefined" `@RalfJung` right? But in either case I'm trying to be surgical in my edit here.
r? Amanieu
Avoid redundant UB check in RangeFrom slice indexing
I noticed this while picking through the IR we generate for https://github.com/rust-lang/rust/pull/134938. I think we just forgot to apply this trick to `RangeFrom`?
Enable `u64` limbs in `core::num::bignum`
Since `u128` is stable now, I guess, we can safely add this, not sure if this requires tests or anything
cc https://github.com/rust-lang/rust/issues/137887
only call polymorphic array iter drop machinery when the type requires it
I saw a bunch of dead, empty `<[core::mem::maybe_uninit::MaybeUninit<T>; N] as core::array::iter::iter_inner::PartialDrop>::partial_drop` functions when compiling with more than 1 CGU.
Let's see if we can help optimizations to eliminate stuff earlier.
r? ghost
Add doc links between `{integer}::from_str_radix` and `from_str`
When parsing base-10 numbers, it's easy to miss `<Self as FromStr>::from_str` and `str::parse` as potential alternatives to `from_str_radix`.
- A similar suggestion is given by https://rust-lang.github.io/rust-clippy/master/index.html#from_str_radix_10
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`
