Skip to content

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Oct 14, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

clarfonthey and others added 30 commits September 5, 2025 17:28
Currently it is possible to avoid linking the allocator shim when
__rust_no_alloc_shim_is_unstable_v2 is defined when linking rlibs
directly as some build systems need. However this requires liballoc to
be compiled with --cfg no_global_oom_handling, which places huge
restrictions on what functions you can call and makes it impossible to
use libstd. Or alternatively you have to define
__rust_alloc_error_handler and (when using libstd)
__rust_alloc_error_handler_should_panic
using #[rustc_std_internal_symbol]. With this commit you can either use
libstd and define __rust_alloc_error_handler_should_panic or not use
libstd and use #[alloc_error_handler] instead. Both options are still
unstable though.

Eventually the alloc_error_handler may either be removed entirely
(though the PR for that has been stale for years now) or we may start
using weak symbols for it instead. For the latter case this commit is a
prerequisite anyway.
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.
Co-Authored-By: Ralf Jung <post@ralfj.de>
Fixes triggering the "only small returns supported" error in the BPF
target.
…=oli-obk

Unstably constify `ptr::drop_in_place` and related methods

Tracking: rust-lang#109342
Supercedes: rust-lang#145725

Makes methods const:

* `core::ptr::drop_in_place`
* `core::mem::ManuallyDrop::drop`
* `core::mem::MaybeUninit::assume_init_drop`
* `<[core::mem::MaybeUninit<_>]>::assume_init_drop`
* `<*mut _>::drop_in_place`
* `core::ptr::NonNull::drop_in_place`
…raheemdev

std: improve handling of timed condition variable waits on macOS

Fixes rust-lang#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#42604 to address rust-lang#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 rust-lang#37440 (comment) 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`.
…trochenkov,RalfJung

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.
…illot,Zalathar

Bitset cleanups

Some minor cleanups I did while working on rust-lang#147619.

r? ```@Zalathar```
…wiser

bpf: return results larger than one register indirectly

Fixes triggering the "only small returns supported" error in the BPF target.
…cottmcm

Replace manual implementation with `carrying_mul_add`

cc rust-lang#146277 (comment)

r? scottmcm
fix missing link to `std::char` in `std` docs

Missed this in rust-lang#147373.
…ouwer

pretty print u128 with display

r? ```@JonathanBrouwer```
…, r=WaffleLapkin

Fewer exceptions in `span()` on parsed attributes

r? ``@JonathanBrouwer``
…r=estebank

Fix ICE caused by associated_item_def_ids on wrong type in resolve diag

Fixes rust-lang#147325

r? ``@estebank``
…=JonathanBrouwer

convert `rustc_main` to the new attribute parsing infrastructure

r? ``@JonathanBrouwer``
…ng, r=JonathanBrouwer

only check duplicates on old/unparsed attributes

r? ``@JonathanBrouwer``

This was effectively already what we were doing, but this was implicit because `.name()` etc were just returning None when dealing with a parsed attribute.... this makes it explicit
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs O-unix Operating system: Unix-like PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Oct 14, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Oct 14, 2025

📌 Commit 545ee6f has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 14, 2025
@bors
Copy link
Collaborator

bors commented Oct 14, 2025

⌛ Testing commit 545ee6f with merge 235a4c0...

bors added a commit that referenced this pull request Oct 14, 2025
Rollup of 12 pull requests

Successful merges:

 - #146187 (Unstably constify `ptr::drop_in_place` and related methods)
 - #146503 (std: improve handling of timed condition variable waits on macOS)
 - #147526 (Move computation of allocator shim contents to cg_ssa)
 - #147630 (Bitset cleanups)
 - #147638 (bpf: return results larger than one register indirectly)
 - #147666 (Replace manual implementation with `carrying_mul_add`)
 - #147669 (fix missing link to `std::char` in `std` docs)
 - #147673 (pretty print u128 with display)
 - #147677 (Fewer exceptions in `span()` on parsed attributes)
 - #147680 (Fix ICE caused by associated_item_def_ids on wrong type in resolve diag)
 - #147682 (convert `rustc_main` to the new attribute parsing infrastructure)
 - #147683 (only check duplicates on old/unparsed attributes)

r? `@ghost`
`@rustbot` modify labels: rollup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs O-unix Operating system: Unix-like PG-exploit-mitigations Project group: Exploit mitigations rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.