You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, many of the core assertions in the standard library make use of the unreachable macro, which is simply an indirection for panic. This is totally fine, but I would like to begin an initiative on upgrading some of these invocations as core::hint::unreachable_unchecked so that we may (at least) give the compiler a chance to optimize the code better.
Below is a non-exhaustive list of possible candidates. I will be editing the issue as more candidates are introduced and as certain examples are marked 100% safe or not.
Merged
None so far.
Definitely Safe
This is the perfect candidate for core::hint::unreachable_unchecked since it is apparent that self is now the Cow::Owned variant.
I would love to send in a PR that resolves this issue! However, I do need some help and guidance from the library maintainers to ensure that undefined behavior is 110% avoided. Feedback on which parts are safe regardless of platform/architecture/hardware is much appreciated.
As mentioned earlier, I will be editing this issue as more people chime in. Thanks!
The text was updated successfully, but these errors were encountered:
6 issues before this (#88600) is a very good reason to not do it and remain unreachable!(). In fact, a lot of ICEs will hit either a unreachable or an unwrap (or similar).
Honestly, this shouldn't be necessary anymore. I sense that there is already a strong consensus that the compiler is (more than) smart enough to detect truly unreachable branches. The panic infrastructure as a safety mechanism is hard to argue against, especially since the compiler already optimizes it away in most cases.
This is great! Glad that I can certainly say that I can close this issue with much greater faith in the compiler's abilities. Thanks for the valuable input, everyone! I believe this issue does not need to linger any longer.
At the moment, many of the core assertions in the standard library make use of the
unreachable
macro, which is simply an indirection forpanic
. This is totally fine, but I would like to begin an initiative on upgrading some of these invocations ascore::hint::unreachable_unchecked
so that we may (at least) give the compiler a chance to optimize the code better.Below is a non-exhaustive list of possible candidates. I will be editing the issue as more candidates are introduced and as certain examples are marked 100% safe or not.
Merged
None so far.
Definitely Safe
This is the perfect candidate for
core::hint::unreachable_unchecked
since it is apparent thatself
is now theCow::Owned
variant.rust/library/alloc/src/borrow.rs
Lines 275 to 287 in 97f2698
Possible Candidates
rust/library/core/src/lazy.rs
Lines 52 to 64 in 673d0db
rust/library/std/src/lazy.rs
Lines 121 to 130 in adf1688
rust/library/std/src/lazy.rs
Lines 152 to 158 in adf1688
rust/library/std/src/sys/sgx/abi/mod.rs
Lines 51 to 52 in 17f30e5
rust/library/std/src/sync/mpsc/oneshot.rs
Lines 105 to 106 in 673d0db
rust/library/std/src/sync/mpsc/oneshot.rs
Lines 170 to 173 in 673d0db
rust/library/std/src/sync/mpsc/oneshot.rs
Lines 188 to 190 in 673d0db
rust/library/std/src/sync/mpsc/oneshot.rs
Lines 251 to 252 in 673d0db
rust/library/std/src/sync/mpsc/oneshot.rs
Lines 278 to 281 in 673d0db
rust/library/std/src/sys/sgx/mutex.rs
Lines 113 to 118 in a28109a
rust/library/core/src/iter/traits/iterator.rs
Lines 3444 to 3449 in 3ed6c1d
rust/library/std/src/sys/sgx/rwlock.rs
Lines 134 to 139 in c5fbcd3
rust/library/core/src/iter/adapters/zip.rs
Lines 182 to 186 in a49e38e
rust/library/core/src/iter/adapters/zip.rs
Lines 219 to 224 in a49e38e
rust/library/std/src/sync/mpsc/stream.rs
Lines 429 to 444 in fe1c942
rust/library/std/src/sync/mpsc/shared.rs
Lines 338 to 343 in 673d0db
rust/library/std/src/sys/unix/kernel_copy.rs
Lines 201 to 207 in dfd7b8d
rust/library/std/src/path.rs
Line 912 in 2ad56d5
rust/library/std/src/net/ip.rs
Lines 1679 to 1684 in a49e38e
rust/library/alloc/src/collections/btree/split.rs
Lines 49 to 56 in 673d0db
rust/library/alloc/src/collections/btree/map.rs
Lines 184 to 187 in 3ed6c1d
rust/library/alloc/src/collections/btree/node.rs
Line 1222 in 23461b2
rust/library/alloc/src/collections/btree/node.rs
Lines 1424 to 1439 in 23461b2
rust/library/alloc/src/collections/btree/node.rs
Lines 1487 to 1503 in 23461b2
rust/library/alloc/src/collections/btree/node.rs
Lines 1599 to 1609 in 23461b2
rust/library/std/src/sync/mpsc/sync.rs
Lines 111 to 114 in 673d0db
rust/library/std/src/sync/mpsc/mod.rs
Line 828 in 607d6b0
rust/library/std/src/sync/mpsc/sync.rs
Line 243 in 673d0db
rust/library/std/src/sync/mpsc/sync.rs
Lines 328 to 342 in 673d0db
rust/library/std/src/sync/mpsc/sync.rs
Lines 378 to 382 in 673d0db
rust/library/std/src/sync/mpsc/sync.rs
Lines 402 to 409 in 673d0db
rust/library/std/src/sync/mpsc/mod.rs
Lines 1157 to 1176 in 607d6b0
Must Remain
unreachable
None so far.
Action
I would love to send in a PR that resolves this issue! However, I do need some help and guidance from the library maintainers to ensure that undefined behavior is 110% avoided. Feedback on which parts are safe regardless of platform/architecture/hardware is much appreciated.
As mentioned earlier, I will be editing this issue as more people chime in. Thanks!
The text was updated successfully, but these errors were encountered: