[pointer] Support generic TransmuteFrom framework

[joshlf]

This commit removes the TransparentWrapper trait and the
Ptr::transparent_wrapper_into_inner method. It replaces them with a
new family of transmutation traits which encode more generic
transmutation (from any T to any U) and a set of Ptr methods which
use those traits to bound transmutation operations.

In particular:

• Dst: TransmuteFrom<Src> denotes that a by-value transmutation is
  sound
• Dst: TryTransmuteFromPtr<Src> denotes that a transmutation is sound
  so long as it can be guaranteed that the source is bit-valid for the
  destination; this is used by e.g. Ptr::try_into_valid, which
  performs runtime validation of bit validity
• Dst: TransmuteFromPtr<Src> is equivalent to TransmuteFrom<Src> + TryTransmuteFromPtr<Src>

Some type arguments are omitted in this summary. In particular, all
three traits also take validity invariant parameters for both the source
and destination types. Also, the [Try]TransmuteFromPtr traits take an
aliasing parameter.

In order to support these traits, we introduce a generalization of
Read known as MutationCompatible. T: MutationCompatible<U, A>
denotes that either T: Read<A> and U: Read<A> or T and U
have the same interior mutation semantics (formally, it is sound for
&T and &U to reference the same referent - safe code operating on
these references cannot cause undefined behavior). This is a refinement
of the "UnsafeCell agreement" concept that we have used before, but it
supports types which store but don't actually use UnsafeCells. For
example, given a hypothetical ReadOnly<T>, the following bound holds:

usize: MutationCompatible<ReadOnly, Exclusive>

This commit also takes a different approach from the one originally
envisioned in #1945. In particular, it turns out that we don't need a
full type-level mapping concept. Instead, we need a predicate over
transitions to determine which ones are valid (e.g., it is valid to go
from a Valid MaybeUninit<T> to an Uninit MaybeUninit<T>). By
contrast, the invariant mapping concept suggests that each source
validity has exactly one destination validity.

This commit makes progress on #1940 by supporting unsized
transmutations, but we don't yet support size shrinking or expanding
transmutations.

This commit obsoletes #1359, as that issue was predicated upon the
existence of TransparentWrapper, which this commit removes.

This commit closes #1226, which suggests supporting UnsafeCell
agreement.

Closes #1945
Closes #1359
Closes #2226
Closes #1226
Closes #1866
Makes progress on #1359

Co-authored-by: Jack Wrenn [email protected]

---

This PR is on branch ptr-validity.

• [pointer] Support generic TransmuteFrom framework #2408

[joshlf]

I think we may have to handle UnsafeCell agreement after all. In particular, in order to implement TryFromBytes for atomics, we need to be able to go from e.g. Ptr<AtomicU8> to Ptr<UnsafeCell<u8>> so that we can call <UnsafeCell<u8> as TryFromBytes>::is_bit_valid. This will require care since this is unsound for shared aliasing. We know in practice that we'll always be using exclusive aliasing, but I'm not sure how to express that generically.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 95.35865% with 11 lines in your changes missing coverage. Please review.

Project coverage is 88.03%. Comparing base (52f65db) to head (64a08b3).

Files with missing lines	Patch %	Lines
src/util/macros.rs	52.94%	8 Missing ⚠️
src/util/macro_util.rs	80.00%	2 Missing ⚠️
src/impls.rs	95.45%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2408      +/-   ##
==========================================
+ Coverage   87.33%   88.03%   +0.70%     
==========================================
  Files          17       17              
  Lines        6451     6412      -39     
==========================================
+ Hits         5634     5645      +11     
+ Misses        817      767      -50     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jswrenn]

Developed and reviewed in tandem!