Document MaybeUninit bit validity
Partially addresses https://github.com/rust-lang/unsafe-code-guidelines/issues/555 by clarifying that it is sound to write any byte values (initialized or uninitialized) to any `MaybeUninit<T>` regardless of `T`.
r? `@RalfJung`
Result/Option layout guarantee clarifications
- It seems worth spelling out that this guarantee allows particular transmutes.
- After the `Result` section was written, the `Option` section it referenced gained *more* guarantees, saying that `None` is represented as `[0u8; N]`. Those guarantees were not meant to apply to `Result`. Make the `Result` section more self-contained to make this more clear.
- "Type has no fields" is unclear since there is no general definition of what the fields of some arbitrary type are. Replace that by a more accurate description of the actual check implemented [here](e379c77586/compiler/rustc_lint/src/types.rs (L828-L838)).
r? `@traviscross`
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`
