Add comments around code where ordering is important due for panic-safety
Iterators contain arbitrary code which may panic. Unsafe code has to be
careful to do its state updates at the right point between calls that may panic.
As requested in https://github.com/rust-lang/rust/pull/86452#discussion_r655153948
r? `@RalfJung`
Iterators contain arbitrary code which may panic. Unsafe code has to be
careful to do its state updates at the right point between calls
that may panic.
Rollup of 11 pull requests
Successful merges:
- #85054 (Revert SGX inline asm syntax)
- #85182 (Move `available_concurrency` implementation to `sys`)
- #86037 (Add `io::Cursor::{remaining, remaining_slice, is_empty}`)
- #86114 (Reopen#79692 (Format symbols under shared frames))
- #86297 (Allow to pass arguments to rustdoc-gui tool)
- #86334 (Resolve type aliases to the type they point to in intra-doc links)
- #86367 (Fix comment about rustc_inherit_overflow_checks in abs().)
- #86381 (Add regression test for issue #39161)
- #86387 (Remove `#[allow(unused_lifetimes)]` which is now unnecessary)
- #86398 (Add regression test for issue #54685)
- #86493 (Say "this enum variant takes"/"this struct takes" instead of "this function takes")
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add `io::Cursor::{remaining, remaining_slice, is_empty}`
Tracking issue: #86369
I came across an inconvenience when answering the following [Stack Overflow](https://stackoverflow.com/questions/67831170) question.
To get the remaining slice you have to call `buff.fill_buf().unwrap()`. Which in my opinion doesn't really tell you what is returned (in the context of Cursor). To improve readability and convenience when using Cursor i propose adding the method `remaining`.
The next thing i found inconvenient (unnecessary long) was detecting if the cursor reached the end. There are a few ways this can be achieved right now:
- `buff.fill_buf().unwrap().is_empty()`
- `buff.position() >= buff.get_ref().len()`
- `buff.bytes().next().is_none()`
Which all seem a bit unintuitive, hidden in trait documentations or just a bit long for such a simple task.
Therefor i propose another method called `is_empty`, maybe with another name, since this one may leave room for interpretation on what really is empty (the underlying slice, the remaining slice or maybe the position).
Since it seemed easier to create this PR instead of an RFC i did that, if an RFC is wanted, i can close this PR and write an RFC first.
Move `available_concurrency` implementation to `sys`
This splits out the platform-specific implementation of `available_concurrency` to the corresponding platforms under `sys`. No changes are made to the implementation.
Tidy didn't lint against this code being originally added outside of `sys` because of a bug (see #84677), this PR also reverts the exclusion that was introduced in that bugfix.
Tracking issue of `available_concurrency`: #74479
Add MIR pass to lower call to `core::slice::len` into `Len` operand
During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator.
It uses some heuristics to remove the outer borrow that is made to call `core::slice::len`, but I assume it can be eliminated, just didn't find how.
Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip
Rollup of 8 pull requests
Successful merges:
- #83739 (Account for bad placeholder errors on consts/statics with trait objects)
- #85637 (document PartialEq, PartialOrd, Ord requirements more explicitly)
- #86152 (Lazify is_really_default condition in the RustdocGUI bootstrap step)
- #86156 (Fix a bug in the linkchecker)
- #86427 (Updated release note)
- #86452 (fix panic-safety in specialized Zip::next_back)
- #86484 (Do not set depth to 0 in fully_expand_fragment)
- #86491 (expand: Move some more derive logic to rustc_builtin_macros)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix panic-safety in specialized Zip::next_back
This was unsound since a panic in a.next_back() would result in the
length not being updated which would then lead to the same element
being revisited in the side-effect preserving code.
fixes#86443
BTree: encapsulate LeafRange better & some debug asserts
Looking at iterators again, I think #81937 didn't house enough code in `LeafRange`. Moving the API boundary a little makes things more local in navigate.rs and less complicated in map.rs.
r? `@Mark-Simulacrum`
Move `OsStringExt` and `OsStrExt` to `std::os`
Moves the `OsStringExt` and `OsStrExt` traits and implementations from `sys_common` to `os`. `sys_common` is for abstractions over `sys` and shouldn't really contain publicly exported items.
This does introduce some duplication: the traits and implementations are now duplicated in `unix`, `wasi`, `hermit`, and `sgx`. However, I would argue that this duplication is no different to how something like `MetadataExt` is duplicated in `linux`, `vxworkx`, `redox`, `solaris` etc. The duplication also matches the fact that the traits on different platforms are technically distinct types: any platform is free to add it's own extra methods to the extension trait.
Use `copy_nonoverlapping` to copy `bytes` in `String::insert_bytes`
The second copy could be made using `ptr::copy_nonoverlapping` instead of `ptr::copy`, since aliasing won't allow `self` and `bytes` to overlap. LLVM even seems to recognize this, [replacing the second `memmove` with a `memcopy`](https://rust.godbolt.org/z/Yoaa6rrGn), so this makes it so it's always applied.
Change entry point to 🛡️ against 💥💥-payloads
Guard against panic payloads panicking within entrypoints, where it is
UB to do so.
Note that there are a number of tradeoffs to consider. For instance, I
considered guarding against accidental panics inside the `rt::init` and
`rt::cleanup` code as well, as it is not all that obvious these may not
panic, but doing so would mean that we initialize certain thread-local
slots unconditionally, which has its own problems.
Fixes#86030
r? `@m-ou-se`
Guard against panic payloads panicking within entrypoints, where it is
UB to do so.
Note that there are a number of implementation approaches to consider.
Some simpler, some more complicated. This particular solution is nice in
that it also guards against accidental implementation issues in
various pieces of runtime code, something we cannot prevent statically
right now.
Fixes#86030
Alter std::cell::Cell::get_mut documentation
I felt that there was some inconsistency between between Cell and RefCell with regards to their `get_mut` method documentation: `RefCell` flags this method as "unusual" in that it takes `&mut self`, while `Cell` does not. I attempted to flag this in `Cell`s documentation as well, and point to `RefCell`s method in the case where it is required.
Find relevant parts of docs and the new version below.
The current docs for `Cell::get_mut`:
> Returns a mutable reference to the underlying data.
This call borrows Cell mutably (at compile-time) which guarantees that we possess the only reference.
And `RefCell::get_mut`:
> Returns a mutable reference to the underlying data.
This call borrows `RefCell` mutably (at compile-time) so there is no need for dynamic checks.
However be cautious: this method expects self to be mutable, which is generally not the case when using a `RefCell`. Take a look at the `borrow_mut` method instead if self isn’t mutable.
Also, please be aware that this method is only for special circumstances and is usually not what you want. In case of doubt, use `borrow_mut` instead.
My attempt to make `Cell::get_mut` clearer:
> Returns a mutable reference to the underlying data.
This call borrows `Cell` mutably (at compile-time) which guaranteesthat we possess the only reference.
However be cautious: this method expects `self` to be mutable, which is generally not the case when using a `Cell`. If you require interior mutability by reference, consider using `RefCell` which provides run-time checked mutable borrows through its `borrow_mut` method.
Stabilize span_open() and span_close().
This proposes to stabilize `Group::span_open()` and `Group::span_close()`.
These are part of the `proc_macro_span` feature gate tracked in https://github.com/rust-lang/rust/issues/54725
Most of the features gated behind `proc_macro_span` are about source location information (file path, line and column information), expansion information (parent()), source_text(), etc. Those are not ready for stabilizaiton. However, getting the span of the `(` and `)` separately instead of only of the entire `(...)` can be very useful in proc macros, and doesn't seem blocked on anything that all the other parts of `proc_macro_span` are blocked on. So, this renames the feature gate for those two functions to `proc_macro_group_span` and stabilizes them.
This was unsound since a panic in a.next_back() would result in the
length not being updated which would then lead to the same element
being revisited in the side-effect preserving code.
Add has_data_left() to BufRead
This is a continuation of #40747 and also addresses #40745. The problem with the previous PR was that it had "eof" in its method name. This PR uses a more descriptive method name, but I'm open to changing it.
Rely on libc for correct integer types in os/unix/net/ancillary.rs.
This PR is a small maintainability improvement. It simplifies `unix/net/ancillary.rs` in `std` by removing the `cfg_ifs` for casting to the correct integer type, and just rely on libc to define the struct correctly.
Specialize `io::Bytes::size_hint` for more types
Improve the result of `<io::Bytes as Iterator>::size_hint` for some readers. I did not manage to specialize `SizeHint` for `io::Cursor`
Side question: would it be interesting for `io::Read` to have an optional `size_hint` method ?
Linear interpolation
#71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author.
The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20.
To ensure symmetry as a method, this breaks the usual ordering of the method from `lerp(a, b, t)` to `t.lerp(a, b)`. This makes the most sense to me personally, and there will definitely be discussion before stabilisation anyway.
Implementing lerp "correctly" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees, which I've simplified down to:
1. Exactness: `(0.0).lerp(start, end) == start` and `(1.0).lerp(start, end) == end`
2. Consistency: `anything.lerp(x, x) == x`
3. Monotonicity: once you go up don't go down
Fun story: the version provided in that proposal, from what I understand, isn't actually monotonic.
I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by, so, just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic, but I'm sure that people who care deeply about this will be there to discuss before stabilisation.
The main reason for using `mul_add` is that, in general, it ticks more boxes with fewer branches to be "correct." Although it will be slower on architectures without the fused `mul_add`, that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.
Make `sum()` and `product()` documentation hyperlinks refer to `Iterator` methods.
The previous linking seemed confusing: within "the sum() method on iterators", "sum()" was linked to `Sum::sum`, not `Iterator::sum`, even though the sentence is talking about the latter. I have rewritten the sentence to be, I believe, clearer, as well as changing the link destinations; applying the same change to the `Product` documentation as well as `Sum`.
I reviewed other traits in the same module and did not see similar issues, and previewed the results using `./x.py doc library/std`.
Remove methods under Implementors on trait pages
As discussed at https://github.com/rust-lang/rust/issues/84326#issuecomment-842652412.
On a trait page, the "Implementors" section currently lists all methods of each implementor. That duplicates the method definitions on the trait itself, and is usually not very useful. So the implementors are collapsed by default. This PR changes rustdoc to just not render them at all. Any documentation specific to an implementor can be found by clicking through to the implementor's page.
This moves the "portability" info inside the `<summary>` tags so it is still visible on trait pages (as originally implemented in #79201). That also means it will be visible on struct/enum pages when methods are collapsed.
Add `#[doc(hidden)]` to all implementations of `Iterator::__iterator_get_unchecked` that didn't already have it. Otherwise, due to #86145, the structs/enums with those implementations would generate documentation for them, and that documentation would have a broken link into the Iterator page. Those links were already "broken" but not detected by the link-checker, because they pointed to one of the Implementors on the Iterator page, which happened to have the right anchor name.
This reduces the Read trait's page size from 128kB to 68kB (uncompressed) and from 12,125 bytes to 9,989 bytes (gzipped
Demo:
https://hoffman-andrews.com/rust/remove-methods-implementors/std/string/struct.String.html#trait-implementationshttps://hoffman-andrews.com/rust/remove-methods-implementors/std/io/trait.Read.html#implementors
r? `@GuillaumeGomez`
Rename IoSlice(Mut)::advance to advance_slice and add IoSlice(Mut)::advance
Also changes the signature of `advance_slice` to accept a `&mut &mut [IoSlice]`, not returning anything. This will better match the `IoSlice::advance` function.
Updates https://github.com/rust-lang/rust/issues/62726.
