Rollup of 12 pull requests #147692
Merged
Rollup of 12 pull requests #147692
+715
−544
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <[email protected]>
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``
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 844264a (parent) -> 235a4c0 (this PR) Test differencesShow 777 test diffsStage 0
Stage 1
Stage 2
(and 86 additional test diffs) Additionally, 591 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 235a4c083eb2a2bfe8779d211c3232f39396de00 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
📌 Perf builds for each rolled up PR:
previous master: 844264adda In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Oct 15, 2025
|
Finished benchmarking commit (235a4c0): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 5.4%, secondary 3.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.7%, secondary 2.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 474.738s -> 474.707s (-0.01%) |
|
@rust-timer build 452b22d |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (452b22d): comparison URL. Overall result: no relevant changes - no action neededInstruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 4.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 2.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 474.738s -> 475.773s (0.22%) |
|
@rust-timer build 99b6c41 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (99b6c41): comparison URL. Overall result: ✅ improvements - no action neededInstruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 3.3%, secondary -2.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -3.4%, secondary 5.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 474.738s -> 475.173s (0.09%) |
|
@rust-timer build ba90c14 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (ba90c14): comparison URL. Overall result: no relevant changes - no action neededInstruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 1.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 474.738s -> 475.257s (0.11%) |
|
@rust-timer build ce53d57 |
|
Queued ce53d57 with parent 844264a, future comparison URL. |
|
edit todo: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
ptr::drop_in_placeand related methods #146187 (Unstably constifyptr::drop_in_placeand related methods)carrying_mul_add#147666 (Replace manual implementation withcarrying_mul_add)std::charinstddocs #147669 (fix missing link tostd::charinstddocs)span()on parsed attributes #147677 (Fewer exceptions inspan()on parsed attributes)rustc_mainto the new attribute parsing infrastructure #147682 (convertrustc_mainto the new attribute parsing infrastructure)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup