Explicitly document the size guarantees that Option makes.
Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of `Option<T>` one can guarantee are optimised to a single pointer.
CC @RalfJung
Std/thread: deny unsafe op in unsafe fn
Partial fix of #73904.
This encloses `unsafe` operations in `unsafe fn` in `libstd/thread`.
`@rustbot` modify labels: F-unsafe-block-in-unsafe-fn
It's possible for method resolution to pick this method over a lower
priority stable method, causing compilation errors. Since this method
is permanently unstable, give it a name that is very unlikely to be used
in user code.
Make [].as_[mut_]ptr_range() (unstably) const.
Gated behind `const_ptr_offset`, as suggested by https://github.com/rust-lang/rust/issues/65807#issuecomment-697229404
This also marks `[].as_mut_ptr()` as const, because it's used by `as_mut_ptr_range`. I gated it behind the same feature, because I figured it's not worth adding a separate tracking issue for const `as_mut_ptr`.
BtreeMap: refactoring around edges
Parts chipped off a more daring effort, that the btree benchmarks judge to be performance-neutral.
r? @Mark-Simulacrum
Relax promises about condition variable.
For quite a while now, there have been plans to at some point use parking_lot or some other more efficient implementation of mutexes and condition variables. Right now, Mutex and CondVar both Box the 'real' mutex/condvar inside, to give it a stable address. This was done because implementations like pthread and Windows critical sections may not be moved. More efficient implementations based on futexes, WaitOnAddress, Windows SRW locks, parking_lot, etc. may be moved (while not borrowed), so wouldn't need boxing.
However, not boxing them (which would be great goal to achieve), breaks a promise std currently makes about CondVar. CondVar promises to panic when used with different mutexes, to ensure consistent behaviour on all platforms. To this check, a mutex is considered 'the same' if the address of the 'real mutex' in the Box is the same. This address doesn't change when moving a `std::mutex::Mutex` object, effectively giving it an identity that survives moves of the Mutex object. If we ever switch to a non-boxed version, they no longer carry such an identity, and this check can no longer be made.
Four options:
1. Always box mutexes.
2. Add a `MutexId` similar to `ThreadId`. Making mutexes bigger, and making it hard to ever have a `const fn new` for them.
3. Making the requirement of CondVar stricter: panic if the Mutex object itself moved.
4. Making the promise of CondVar weaker: don't promise to panic.
1, 2, and 3 seem like bad options. This PR updates the documentation for 4.
Use `Self` in docs when possible
Fixes#76542.
I used `rg '\s*//[!/]\s+fn [\w_]+\(&?self, ' .` in `library/` to find instances, I found some with that and some by manually checking.
@rustbot modify labels: C-enhancement T-doc
add array::from_ref
mirrors the methods in `std::slice` with the same name.
I guess this method previously didn't exist as there was close to no reason to create an array of size `1`.
This will change due to const generics in the near future.
Make delegation methods of `std::net::IpAddr` unstably const
Make the following methods of `std::net::IpAddr` unstable const under the `const_ip` feature:
- `is_unspecified`
- `is_loopback`
- `is_global`
- `is_multicast`
Also adds a test for these methods in a const context.
Possible because these methods delegate to the inner `Ipv4Addr` or `Ipv6Addr`, which were made const ([PR#76205](https://github.com/rust-lang/rust/pull/76142) and [PR#76206](https://github.com/rust-lang/rust/pull/76206)), and the recent stabilization of const control flow.
Part of #76205
r? @ecstatic-morse
revert const_type_id stabilization
This reverts #72488, which is currently on beta and scheduled to stabilize in `1.47.0`, based on https://github.com/rust-lang/rust/pull/75923#issuecomment-696676511
It turns out we might not be quite ready to stabilize `TypeId` in const contexts before having a chance to rework its internals. Since `TypeId` is a bit of an oddity we want to be careful about how those internals are currently being relied on while making changes. That will be easier to do without having to also consider compile-time contexts.
r? `@eddyb`
Rollup of 9 pull requests
Successful merges:
- #76898 (Record `tcx.def_span` instead of `item.span` in crate metadata)
- #76939 (emit errors during AbstractConst building)
- #76965 (Add cfg(target_has_atomic_equal_alignment) and use it for Atomic::from_mut.)
- #76993 (Changing the alloc() to accept &self instead of &mut self)
- #76994 (fix small typo in docs and comments)
- #77017 (Add missing examples on Vec iter types)
- #77042 (Improve documentation for ToSocketAddrs)
- #77047 (Miri: more informative deallocation error messages)
- #77055 (Add #[track_caller] to more panicking Cell functions)
Failed merges:
r? `@ghost`
Make the following methods of `std::net::IpAddr` unstable const under the `const_ip` feature:
- `is_unspecified`
- `is_loopback`
- `is_global`
- `is_multicast`
Also adds a test for these methods in a const context.
Possible because these methods delegate to the inner `Ipv4Addr` or `Ipv6Addr`, which were made const, and the recent stabilization of const control flow.
Part of #76205
Add #[track_caller] to more panicking Cell functions
Continuation of #74526
Adds the #[track_caller] attribute to almost all panicking Cell
functions. The ones that borrow two Cells in their function
body are spared, because the panic location helps pinpoint
which of the two borrows failed. You'd need to have
full debuginfo and backtraces enabled together with column
info in order to be able to discern the cases.
Column info in debuginfo is only available on non-Windows platforms.
Add cfg(target_has_atomic_equal_alignment) and use it for Atomic::from_mut.
Fixes some platform-specific problems with #74532 by using the actual alignment of the types instead of hardcoding a few `target_arch`s.
r? @RalfJung
Continuation of #74526
Adds the #[track_caller] attribute to almost all panicking Cell
functions. The ones that borrow two Cells in their function
body are spared, because the panic location helps pinpoint
which of the two borrows failed. You'd need to have
full debuginfo and backtraces enabled together with column
info in order to be able to discern the cases.
Column info is only available on non-Windows platforms.
