Update subtree/library to 2025-12-04#608
Open
github-actions[bot] wants to merge 18 commits into
Open
Conversation
…sor` As discussed extensively in libs-api, the initialized-bytes tracking primarily benefits calls to `read_buf` that end up initializing the buffer and calling `read`, at the expense of calls to `read_buf` that *don't* need to initialize the buffer. Essentially, this optimizes for the past at the expense of the future. If people observe performance issues using `read_buf` (or something that calls it) with a given `Read` impl, they can fix those performance issues by implementing `read_buf` for that `Read`. Update the documentation to stop talking about initialized-but-unfilled bytes. Remove all functions that just deal with those bytes and their tracking, and remove usage of those methods. Remove `BorrowedCursor::advance` as there's no longer a safe case for advancing within initialized-but-unfilled bytes. Rename `BorrowedCursor::advance_unchecked` to `advance`. Update tests.
At least on OVMF, some files copied over from linux file system seem to have invalid time (year = 1980 and everything else 0). Since Rust allows time to be optional and we can return error, that seems to be the way to go for now. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Slice iter cleanup
array_chunks: slightly improve docs
also introduce Peekable::next_if_map_mut next to next_if_map As requested in rust-lang#148941 (comment) by ``@joshtriplett``
std: sys: fs: uefi: Make time in FileAttr optional At least on OVMF, some files copied over from linux file system seem to have invalid time (year = 1980 and everything else 0). Since Rust allows time to be optional, and we can return error, that seems to be the way to go for now. `@rustbot` label +O-UEFI
…tracking, r=Amanieu Remove initialized-bytes tracking from `BorrowedBuf` and `BorrowedCursor` As discussed extensively in libs-api, the initialized-bytes tracking primarily benefits calls to `read_buf` that end up initializing the buffer and calling `read`, at the expense of calls to `read_buf` that *don't* need to initialize the buffer. Essentially, this optimizes for the past at the expense of the future. If people observe performance issues using `read_buf` (or something that calls it) with a given `Read` impl, they can fix those performance issues by implementing `read_buf` for that `Read`. Update the documentation to stop talking about initialized-but-unfilled bytes. Remove all functions that just deal with those bytes and their tracking, and remove usage of those methods. Remove `BorrowedCursor::advance` as there's no longer a safe case for advancing within initialized-but-unfilled bytes. Rename `BorrowedCursor::advance_unchecked` to `advance`. Update tests. r? ``@Amanieu``
…onszelmann Remove an outdated test This... is a weird test. It has two impls: - `impl<T> From<Foo<T>> for Box<T>` (commented out, more on that later), and - `impl<T> Into<Vec<T>> for Foo<T>` The idea of that test is to show that the first impl doesn't compile, but the second does, thus `TryFrom` should be using `Into` and not `From` (because `Into` is more general, since the `From` impl doesn't compile). However: 1. The types are different -- `Box` vs `Vec`, which is significant b/c `Box` is fundamental 2. The commented out impl actually compiles! (which wasn't detected b/c it's commented out :\ ) Here is a table for compilation of the impls: | | `Vec` | `Box` | |--------|--------------|----------------| | `From` | since 1.41.0 | never | | `Into` | always | not since 1.28 | [godbolt used to test this](https://godbolt.org/z/T38E3jGKa) Order of events: 1. in `1.28` the `incoherent_fundamental_impls` lint becomes deny by default (this is *not* mentioned in the changelog yay) 2. `1.32` changed absolutely nothing, even though this version is credited in the test 3. the test was added (I'm not exactly sure when) (see rust-lang#56796) 4. in `1.41` coherence was relaxed to allow `From`+`Vec` to compile To conclude: since `1.41` this test does nothing (and before that it was written in a way which did not detect this change). It looks to me like today (since `1.41`) we *could* bound `TryFrom` impl with `From` (but now it'd be a useless breaking change of course). Am I missing anything? Is there a useful version of this test that could be written?
…=ChrisDenton Fix std::mem::drop rustdoc misleading statement This is a bit misleading, we were discussing this with our Rust team and some people could think that the compiler does some special magic for this specific function and that's not true or well the compiler does something special but for every function. The reality according to my understanding is that this is a normal function that takes ownership of the given value and as with every other function mir building injects Drop Terminators , drop elaboration refines this and then we would insert the corresponding drop glue, then potentially calling Drop::drop. Not sure if it would be best to remove the sentence as this PR does or explaining something along the lines of the previous text.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 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.
This is an automated PR to update the subtree/library branch to the changes from 2025-10-09 (rust-lang/rust@b6f0945) to 2025-12-04 (rust-lang/rust@83e49b7), inclusive.
Review this PR as usual, but do not merge this PR using the GitHub web interface. Instead, once it is approved, use
git pushto literally push the changes tosubtree/librarywithout any rebase or merge.