std::thread spawn: Docs: Link to Builder::spawn; Make same.
Replace "use this API instead" with a link to Builder::spawn. Edit the paragraph to make it slightly clearer.
The Scope::spawn method already included a link to `Builder::spawn_scoped`. Make the docs for `Scope::spawn` and `thread::spawn` nearly the same.
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](https://github.com/rust-lang/rust/blob/e379c7758667f900aaf5551c4553c7d4c121e3e1/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.
std: Add Motor OS std library port
Motor OS was added as a no-std Tier-3 target in
[PR 146848](https://github.com/rust-lang/rust/pull/146848) as x86_64-unknown-motor.
This PR adds the std library for Motor OS.
While the PR may seem large, all it does is proxy
std pal calls to [moto-rt](https://crates.io/crates/moto-rt). Where there is some non-trivial
code (e.g. thread::spawn), it is quite similar, often
identical, to what other platforms do.
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
Stabilize `rwlock_downgrade` library feature
Tracking Issue: https://github.com/rust-lang/rust/issues/128203
Method to be stabilized:
```rust
impl<'a, T: ?Sized> RwLockWriteGuard<'a, T> {
pub fn downgrade(s: Self) -> RwLockReadGuard<'a, T> {}
}
```
~~I would like to point out that my documentation comment is longer than ideal, but at the same time I don't really know how else to show why `downgrade` is actually necessary (instead of just unlocking and relocking). If anyone has ideas for making this more concise that would be great!~~ I have made the documentation a bit more clear.
Stabilization report: https://github.com/rust-lang/rust/issues/128203#issuecomment-3016682463
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
Move computation of allocator shim contents to cg_ssa
In the future this should make it easier to use weak symbols for the allocator shim on platforms that properly support weak symbols. And it would allow reusing the allocator shim code for handling default implementations of the upcoming externally implementable items feature on platforms that don't properly support weak symbols.
In addition to make this possible, the alloc error handler is now handled in a way such that it is possible to avoid using the allocator shim when liballoc is compiled without `no_global_oom_handling` if you use `#[alloc_error_handler]`. Previously this was only possible if you avoided liballoc entirely or compiled it with `no_global_oom_handling`. You still need to avoid libstd and to define the symbol that indicates that avoiding the allocator shim is unstable.
std: improve handling of timed condition variable waits on macOS
Fixesrust-lang/rust#37440 (for good).
This fixes two issues with `Condvar::wait_timeout` on macOS:
Apple's implementation of `pthread_cond_timedwait` internally converts the absolute timeout to a relative one, measured in nanoseconds, but fails to consider overflow when doing so. This results in `wait_timeout` returning much earlier than anticipated when passed a duration that is slightly longer than `u64::MAX` nanoseconds (around 584 years). The existing clamping introduced by rust-lang/rust#42604 to address rust-lang/rust#37440 unfortunately used a maximum duration of 1000 years and thus still runs into the bug when run on older macOS versions (or with `PTHREAD_MUTEX_USE_ULOCK` set to a value other than "1"). See https://github.com/rust-lang/rust/issues/37440#issuecomment-3285958326 for context.
Reducing the maximum duration alone however would not be enough to make the implementation completely correct. As macOS does not support `pthread_condattr_setclock`, the deadline passed to `pthread_cond_timedwait` is measured against the wall-time clock. `std` currently calculates the deadline by retrieving the current time and adding the duration to that, only for macOS to convert the deadline back to a relative duration by [retrieving the current time itself](https://github.com/apple-oss-distributions/libpthread/blob/1ebf56b3a702df53213c2996e5e128a535d2577e/src/pthread_cond.c#L802-L819) (this conversion is performed before the aforementioned problematic one). Thus, if the wall-time clock is adjusted between the `std` lookup and the system lookup, the relative duration could have changed, possibly even to a value larger than $2^{64}\ \textrm{ns}$. Luckily however, macOS supports the non-standard, tongue-twisting `pthread_cond_timedwait_relative_np` function which avoids the wall-clock-time roundtrip by taking a relative timeout. Even apart from that, this function is perfectly suited for `std`'s purposes: it is public (albeit badly-documented) API, [available since macOS 10.4](https://github.com/apple-oss-distributions/libpthread/blob/1ebf56b3a702df53213c2996e5e128a535d2577e/include/pthread/pthread.h#L555-L559) (that's way below our minimum of 10.12) and completely resilient against wall-time changes as all timeouts are [measured against the monotonic clock](https://github.com/apple-oss-distributions/xnu/blob/e3723e1f17661b24996789d8afc084c0c3303b26/bsd/kern/sys_ulock.c#L741) inside the kernel.
Thus, this PR switches `Condvar::wait_timeout` to `pthread_cond_timedwait_relative_np`, making sure to clamp the duration to a maximum of $2^{64} - 1 \ \textrm{ns}$. I've added a miri shim as well, so the only thing missing is a definition of `pthread_cond_timedwait_relative_np` inside `libc`.
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`?
std: implement `pal::os::exit` for VEXos
This PR provides a more "proper" implementation of process exiting in VEXos programs by going through `vexSystemExitRequest` rather than calling `intrinsics::abort`, which exits using an undefined instruction trap. This matches the existing implementation of `rt::abort_internal` and therefore makes `std::process::exit` have the same behavior as returning from main on VEXos targets.
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
Perform unused assignment and unused variables lints on MIR.
Rebase of https://github.com/rust-lang/rust/pull/101500
Fixes https://github.com/rust-lang/rust/issues/51003.
The first commit moves detection of uninhabited types from the current liveness pass to MIR building.
In order to keep the same level of diagnostics, I had to instrument MIR a little more:
- keep for which original local a guard local is created;
- store in the `VarBindingForm` the list of introducer places and whether this was a shorthand pattern.
I am not very proud of the handling of self-assignments. The proposed scheme is in two parts: first detect probable self-assignments, by pattern matching on MIR, and second treat them specially during dataflow analysis. I welcome ideas.
Please review carefully the changes in tests. There are many small changes to behaviour, and I'm not sure all of them are desirable.
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.
bors