resolve code review comments
This commit is contained in:
parent
5a9e5e4acf
commit
d23df74712
@ -23,7 +23,7 @@
|
||||
/// type. Many asynchronous foundation crates provide such a `Mutex` type.
|
||||
/// The other solution is to ensure the mutex is unlocked before calling
|
||||
/// `await`, either by introducing a scope or an explicit call to
|
||||
/// [`Drop::drop`].
|
||||
/// [`Drop::drop`](https://doc.rust-lang.org/std/ops/trait.Drop.html).
|
||||
///
|
||||
/// ### Known problems
|
||||
/// Will report false positive for explicitly dropped guards
|
||||
|
@ -219,7 +219,7 @@
|
||||
/// Dereferencing the resulting pointer may be undefined behavior.
|
||||
///
|
||||
/// ### Known problems
|
||||
/// Using [`std::ptr::read_unaligned`] and [`std::ptr::write_unaligned`] or
|
||||
/// Using [`std::ptr::read_unaligned`](https://doc.rust-lang.org/std/ptr/fn.read_unaligned.html) and [`std::ptr::write_unaligned`](https://doc.rust-lang.org/std/ptr/fn.write_unaligned.html) or
|
||||
/// similar on the resulting pointer is fine. Is over-zealous: casts with
|
||||
/// manual alignment checks or casts like `u64` -> `u8` -> `u16` can be
|
||||
/// fine. Miri is able to do a more in-depth analysis.
|
||||
|
Loading…
Reference in New Issue
Block a user