| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This makes the following API stable in const contexts:
impl<T> Option<T> {
pub const fn as_mut(&mut self) -> Option<&mut T>;
pub const fn expect(self, msg: &str) -> T;
pub const fn unwrap(self) -> T;
pub const unsafe fn unwrap_unchecked(self) -> T;
pub const fn take(&mut self) -> Option<T>;
pub const fn replace(&mut self, value: T) -> Option<T>;
}
impl<T> Option<&T> {
pub const fn copied(self) -> Option<T>
where T: Copy;
}
impl<T> Option<&mut T> {
pub const fn copied(self) -> Option<T>
where T: Copy;
}
impl<T, E> Option<Result<T, E>> {
pub const fn transpose(self) -> Result<Option<T>, E>
}
impl<T> Option<Option<T>> {
pub const fn flatten(self) -> Option<T>;
}
The following functions make use of the unstable
`const_precise_live_drops` feature:
- `expect`
- `unwrap`
- `unwrap_unchecked`
- `transpose`
- `flatten`
Fixes: <https://github.com/rust-lang/rust/issues/67441>
|
|
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.
https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
MIRI support is included for f32 and f64.
The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.
I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
|
|
|
|
Prefer refutable slice patterns over len check + index op
Just something I noticed while reviewing other PRs
We do it for shim arguments almost everywhere, but when the size is not statically known, we didn't use the helpers as they rely on array ops. But we can avoid a len check followed by several index ops by just using a refutable slice pattern with `let else`.
The pattern is so common, it seems almost worth a dedicated macro
|
|
pthread mutex: better error in reentrant-locking-UB
Also test reentrant locking of PTHREAD_MUTEX_INITIALIZER
|
|
PTHREAD_MUTEX_INITIALIZER
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
std: make `thread::current` available in all `thread_local!` destructors
... and thereby allow the panic runtime to always print the right thread name.
This works by modifying the TLS destructor system to schedule a runtime cleanup function after all other TLS destructors registered by `std` have run. Unfortunately, this doesn't affect foreign TLS destructors, `thread::current` will still panic there.
Additionally, the thread ID returned by `current_id` will now always be available, even inside the global allocator, and will not change during the lifetime of one thread (this was previously the case with key-based TLS).
The mechanisms I added for this (`local_pointer` and `thread_cleanup`) will also allow finally fixing #111272 by moving the signal stack to a similar runtime-cleanup TLS variable.
|
|
A simplification that doesn't impact the epoll implementation's logic.
It is not necessary to clone the ready_list before reading its
`is_empty` state.
This avoids the clone step but more importantly avoids the invisible
drop step of the clone.
|
|
This adds a VClock to the epoll implementation's ready_list
and has this VClock synced from the thread that updates
an event in the ready_list and then has the VClocks of any
threads being made runnable again, out of the calls to
epoll_wait, synced from it.
|
|
A couple of instructions were left over from an earlier rebase
it would seem. They don't impact the logic but the ready_list type
is about to change in the next commit.
Rather than modify one of these lines in the commit that changes
ready_list, only to have these lines removed later on, remove them now.
They don't impact the tests results.
|
|
This test demonstrates the need to synchronize the clock
of the thread waking up from an epoll_wait from the thread
that issued the epoll awake event.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Miri subtree update
r? `@ghost`
|
|
|
|
|
|
|
|
implements arc4random_buf shim for freebsd/solarish platforms.
close #3914
|
|
|
|
close #3914
|
|
|
|
- UnsafeCell: mention the term "data race", and reference the data race definition
- atomic: failing RMWs are just reads, reorder and reword docs
|
|
|
|
|
|
|
|
Automatic Rustup
|
|
|
|
|
|
|
|
|
|
|
|
switch custom target JSON test to a less exotic target
We used to test an AVR target here, but while it is nice to test a 16bit target, it is also currently the case that rustc CI does not even check that libcore builds on a 16bit target -- and we don't want Miri to be in the game of maintaining that support. (See https://github.com/rust-lang/rust/issues/130818.)
So let's use a tier 2 target as the basis for testing a custom JSON target.
(FWIW, we also test wasm32-wasip2 which is tier 3, but I expect it will become tier 2 Soon-ish.)
|
|
|
|
|
|
|
|
|
