-
Notifications
You must be signed in to change notification settings - Fork 48
Update subtree/library to 2025-04-04 #317
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
Conversation
Remove unsafe `split_at_unchecked` and `split_at_mut_unchecked` in some slice `split_first_chunk`/`split_last_chunk` methods. Replace those calls with the safe `split_at` and `split_at_checked` where applicable. Add codegen tests to check for no panics when calculating the last chunk index using `checked_sub` and `split_at`
Do the following: * Switch to `impl FnOnce` rather than a generic `F`. * Change `update` to return nothing. This was discussed at a libs-api meeting [1]. Tracking issue: rust-lang#50186 [1]: rust-lang#134446 (comment)
slice: Remove some uses of unsafe in first/last chunk methods Remove unsafe `split_at_unchecked` and `split_at_mut_unchecked` in some slice `split_first_chunk`/`split_last_chunk` methods. Replace those calls with the safe `split_at` and `split_at_checked` where applicable. Add codegen tests to check for no panics when calculating the last chunk index using `checked_sub` and `split_at`. Better viewed with whitespace disabled in diff view --- The unchecked calls are mostly manual implementations of the safe methods, but with the safety condition negated from `mid <= len` to `len < mid`. ```rust if self.len() < N { None } else { // SAFETY: We manually verified the bounds of the split. let (first, tail) = unsafe { self.split_at_unchecked(N) }; // Or for the last_chunk methods let (init, last) = unsafe { self.split_at_unchecked(self.len() - N) }; ``` Unsafe is still needed for the pointer array casts. Their safety comments are unmodified.
…pratt Apply requested API changes to `cell_update` Do the following: * Switch to `impl FnOnce` rather than a generic `F`. * Change `update` to return nothing. This was discussed at a libs-api meeting [1]. Tracking issue: rust-lang#50186 [1]: rust-lang#134446 (comment)
…iter, r=dtolnay Make slice iterator constructors unstably const See [tracking issue](rust-lang#137737) for justification. try-job: aarch64-apple try-job: x86_64-gnu
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#139080 (Experimental feature gate for `super let`) - rust-lang#139145 (slice: Remove some uses of unsafe in first/last chunk methods) - rust-lang#139149 (unstable book: document import_trait_associated_functions) - rust-lang#139273 (Apply requested API changes to `cell_update`) - rust-lang#139282 (rustdoc: make settings checkboxes always square) - rust-lang#139283 (Rustc dev guide subtree update) - rust-lang#139294 (Fix the `f16`/`f128` feature gates on integer literals) r? `@ghost` `@rustbot` modify labels: rollup
I fear we have a problem--the changes in here appear to be a subset of those in #318. For example, #318 has the changes from rust-lang#138492 incorporated. That PR was merged on 4/1, so it should also appear here. |
I'm not entirely sure this a bug here: we have #315 merged, which did not have a corresponding merge-to-main PR, because the prior merge-to-main was still open. So branch "subtree/library" is actually further ahead than "main". |
This is an automated PR to update the subtree/library branch to the changes from 2025-04-01 (rust-lang/rust@0b45675) to 2025-04-04 (rust-lang/rust@00095b3), inclusive.
Review this PR as usual, but do not merge this PR using the GitHub web interface. Instead, once it is approved, use
git push
to literally push the changes tosubtree/library
without any rebase or merge.