-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #133694
Rollup of 8 pull requests #133694
Conversation
The non-trivial code for `pthread_condvar` is duplicated across the thread parking and the `Mutex`/`Condvar` implementations. This PR moves that code into `sys::pal`, which now exposes a non-movable wrapper type for `pthread_mutex_t` and `pthread_condvar_t`.
The link was introduced in 0ec321f. For the old link see https://web.archive.org/web/20170409223244/https://monoinfinito.wordpress.com/series/exception-handling-in-c/. The blog has migrated from WordPress to Blogger in 2021 and to GitHub pages in 2024.
This will be used in Clippy to detect useless conversions done through `ControlFlow::map_break()` and `ControlFlow::map_continue()`.
…rkingjubilee std: refactor `pthread`-based synchronization The non-trivial code for `pthread_condvar` is duplicated across the thread parking and the `Mutex`/`Condvar` implementations. This PR moves that code into `sys::pal`, which now exposes an `unsafe` wrapper type for `pthread_mutex_t` and `pthread_condvar_t`.
…=cjgillot Robustify and genericize return-type-notation resolution in `resolve_bound_vars` rust-lang#129629 implemented return-type-notation (RTN) in its path form, like `where T::method(..): Bound`. As part of lowering, we must record the late-bound vars for the where clause introduced by the method (namely, its early- and late-bound lifetime arguments, since `where T::method(..)` turns into a higher-ranked where clause over all of the lifetimes according to [RFC 3654](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds)). However, this logic was only looking at the where clauses of the parent item that the `T::method(..)` bound was written on, and not any parent items. This PR generalizes that logic to look at the parent item (i.e. the outer impl or trait) instead and fixes a (debug only) assertion as an effect. This logic is also more general and likely easier to adapt to more interesting (though likely very far off) cases like non-lifetime binder `for<T: Trait> T::method(..): Send` bounds. Tracking: - rust-lang#109417
fix: hurd build, stat64.st_fsid was renamed to st_dev On hurd, `stat64.st_fsid` was renamed to `st_dev` in rust-lang/libc#3785, so if you have a new libc with this patch included, and you build std from source, you get this error: ```sh error[E0609]: no field `st_fsid` on type `&stat64` --> /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/os/hurd/fs.rs:301:36 | 301 | self.as_inner().as_inner().st_fsid as u64 | ^^^^^^^ unknown field | help: a field with a similar name exists | 301 | self.as_inner().as_inner().st_uid as u64 | ~~~~~~ ``` Full CI log: https://github.com/nix-rust/nix/actions/runs/12033180710/job/33546728266?pr=2544
…codeblocks, r=cuviper fix: fix codeblocks in `PathBuf` example This PR adds missing codeblocks around an example included in the `PathBuf` documentation.
update link to "C++ Exceptions under the hood" blog The link was introduced in 0ec321f. For the old link, see https://web.archive.org/web/20170409223244/https://monoinfinito.wordpress.com/series/exception-handling-in-c/. The blog has migrated from WordPress to Blogger in 2021 and to GitHub pages in 2024.
…assoc, r=lcnr Do not create trait object type if missing associated types r? lcnr
…=compiler-errors Add diagnostic item for `std::ops::ControlFlow` This will be used in Clippy to detect useless conversions done through `ControlFlow::map_break()` and `ControlFlow::map_continue()`.
Fixed typos by changing `happend` to `happened` I just noticed this typo before and decided to fix it :3
@bors r+ rollup=never p=8 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 8ac313bdbe In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (6c76ed5): 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 countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 2.4%, secondary 2.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
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: 769.103s -> 767.632s (-0.19%) |
Most of the regressions are in doc-full scenarios, and I don't see anything that is obviously a culprit. @rust-timer build cc255a3 |
Successful merges:
pthread
-based synchronization #128184 (std: refactorpthread
-based synchronization)resolve_bound_vars
#132047 (Robustify and genericize return-type-notation resolution inresolve_bound_vars
)PathBuf
example #133602 (fix: fix codeblocks inPathBuf
example)std::ops::ControlFlow
#133686 (Add diagnostic item forstd::ops::ControlFlow
)happend
tohappened
#133689 (Fixed typos by changinghappend
tohappened
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup