Taiki Endo
Taiki Endo
`unix::DirBuilderExt`, `unix::DirEntryExt`, `unix::OpenOptionsExt`, and `windows::OpenOptionsExt` are not intended to be implemented by users, and they should be [sealed](https://rust-lang.github.io/api-guidelines/future-proofing.html#sealed-traits-protect-against-downstream-implementations-c-sealed). Note that this is a breaking change. (However, given the standard library...
~~(Depend on https://github.com/taiki-e/atomic-maybe-uninit/pull/16.)~~ This fixes UB when lock-free and the value has uninitialized bytes, by using [atomic-maybe-uninit](https://github.com/taiki-e/atomic-maybe-uninit) crate. Fixes #315 Fixes #748 Also, this makes 128-bit atomics lock-free on some...
Include https://github.com/rust-lang/rust/issues/107466 's case. cc https://github.com/rust-lang/rust/pull/108164
As I said in https://github.com/rust-lang/rust/issues/106668#issuecomment-1378136621, the current behavior is a bit confusing.
This would help avoid problems like https://github.com/rust-lang/futures-rs/pull/2801#issuecomment-1819252187. rust-lang/rust already has a mechanism for this (https://github.com/rust-lang/rust/pull/118607#issuecomment-1838839291), but I don't know how to enable it for this repo.
This is a tracking issue for consistency in APIs that use closures in futures 0.4. For individual cases, see below. (Especially #1889, #2470, and #2518 have some discussion on this)...
https://docs.rs/futures/latest/futures/io/struct.ReadHalf.html > The readable half of an object returned from `AsyncRead::split`. https://docs.rs/futures/latest/futures/io/struct.WriteHalf.html > The writable half of an object returned from `AsyncRead::split`. Both should be "... returned from `AsyncReadExt::split`"
https://docs.rs/futures/latest/futures/io/struct.Take.html#method.get_ref > Acquires a reference to the underlying **sink or stream** that this combinator is pulling from. These methods are defined by the delegate_access_inner macro and we need to fix...