Previously, we supported the `AtLeast` bound, which was used to describe
a subset relationship in which `I: AtLeast<J>` implied that `I` as at
least as restrictive as `J`. However, as described in #1866, this
incorrectly models invariants as monotonic. In reality, invariants both
provide guarantees but also *require* guarantees.

This commit takes a step in the direction of resolving #1866 by removing
`AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference`
trait, which is implemented for `Shared` and `Exclusive`. This serves
two purposes: First, it makes it explicit what this bound means.
Previously, `AtLeast<Shared>` had an ambiguous meaning, while
`Reference` means precisely that an invariant is either `Shared` or
`Exclusive` and nothing else. Second, it paves the way for #1183, in
which we may add new aliasing invariants which convey ownership. In that
case, it will be important for existing methods to add `Reference`
bounds when those methods would not be sound in the face of ownership
semantics.

We also inline the items in the `invariant` module, which were
previously generated by macro. The addition of the `Reference` trait did
not play nicely with that macro, and we will likely need to go further
from the macro in order to fix #1839 – this fix will likely require
making aliasing invariants meaningfully different than other invariants,
for example by adding an associated type.

Makes progress on #1866

gherrit-pr-id: I86ef959643b97a34da81bf55a1fed5060b9cf6b2

`PtrInner` carries all invariants which are not controlled by type
parameters. Since `PtrInner` does not promise to uphold aliasing,
alignment, or validity, we can move some utility methods to `PtrInner`
which previously were responsible for maintaining invariants orthogonal
to their purpose.

Makes progress on #1892 (still needs to be fixed on v0.8.x)
Closes #1890

gherrit-pr-id: I1c2d4a54bc1d73d3079d043c2bc393a8967f44f6

Explain why we only support concrete types so that future authors won't
spuriously add support for them.

Co-authored-by: Joshua Liebow-Feeser <joshlf@users.noreply.github.com>

This prepares us for future changes which will significantly increase
the amount of code in the `invariant` module.

Also merge `aliasing_safety` into this new file.

Co-authored-by: Joshua Liebow-Feeser <joshlf@users.noreply.github.com>

`AliasingSafe` is really about whether a pointer permits unsynchronized
reads - either because the referent contains no `UnsafeCell`s or because
the aliasing mode is `Exclusive`. Previously, `AliasingSafe` was not
named consistent with this meaning, and was a function of a *pair* of
types rather than of a single type. This commit fixes both oversights.

While we're here, we also add `Read` bounds in some places, allowing us
to simplify many safety comments.

gherrit-pr-id: I88b9101a614459af3b062dc3d38142ba76427f34

For aliasing, use `Inaccessible`. For alignment and validity, use
`Unknown`.

gherrit-pr-id: I6b21a2d3a712196aed8897780da405dbc4ac6da1

* [ci] fix, showing cache hit, re-install dependencies

* [ci] fix ci workflow to check the cache-hit output and add restore-key for wider cache range

Co-authored-by: Eden <eden.chen@bath.edu>

)

We previously used `AliasingMapping`s and `Inaccessible` to model
`UnsafeCell` agreement. This abuses the notion of a mapping since one
doesn't ever actually want to change the aliasing of a pointer (and
certainly not to `Inaccessible`) - really this was meant to model
pointer casts which should never be performed. In addition to being an
awkward fit, the presence of `Inaccessible` meant that code could not
assume that any `Aliasing` invariant permitted reading, and so we had to
add extra machinery to work around this.

Future commits will use a different, simpler model for denoting
`UnsafeCell` agreement or disagreement.

While we're here, make `Read` slightly more permissive, implemented for
`A: Aliasing, T: Immutable` rather than just `A: Reference, T:
Immutable`.

Makes progress on #1122, #1866

gherrit-pr-id: I1ac2ae177a235083e33b09fc848423220d3da042

…2390)

Co-authored-by: Aditya Pratap Singh <adityapratapsjnhh7654@gmail.com>

)

* [ci] Add GitHub Action to backport PR (#2017)

Closes #2014

gherrit-pr-id: I70bf2382d041da61ff8d85be9fc593cacc08e215

* [ci][backport-pr] Fetch all commits, configure git author (#2018)

gherrit-pr-id: I8c3db36d20b511c31ec774db68896f2fe4b539bb

We already have the merge queue; running on push is redundant.

gherrit-pr-id: I48ecff7f2ed189bf87ba0dcb451345c0d0278b83

Previously, `Ptr<'a, T>` and `PtrInner<'a, T>` documented themselves to
be covariant in both `'a` and `T`. This was true for `PtrInner`, but not
for `Ptr`, which used GATs, which are invariant. This is also not the
desired variance: for `Exclusive` aliasing, the desired variance matches
that of `&mut` references - namely, covariant in `'a` but invariant in
`T`.

This commit fixes this by making `Ptr<'a, T>` and `PtrInner<'a, T>`
unconditionally covariant in `'a` and invariant in `T`.

gherrit-pr-id: I29f8429d9d7b14026313f030f8dc1e895a98ad56

gherrit-pr-id: I8aec00c4246e0e9f80c90c3295ffd79921d4d8b3

Co-authored-by: Joshua Liebow-Feeser <joshlf@users.noreply.github.com>

This commit makes the following improvements:
- Removes the `Inaccessible` aliasing mode. This mode was not unsound,
  but it was unnecessary in practice.
- Replaces `Unknown` with `Unaligned` for alignment.
- Replaces `Unknown` with `Uninit` for validity.

Finally, with the exception of `transparent_wrapper_into_inner`, this
commit ensures that all `Ptr` methods which modify the type or validity
of a `Ptr` are sound.

Previously, we modeled validity as "knowledge" about the `Ptr`'s
referent (see #1866 for a more in-depth explanation). In particular, we
assumed that it was always sound to "forget" information about a `Ptr`'s
referent in the same way in which it is sound to "forget" that a `Ptr`
is validly-aligned, converting a `Ptr<T, (_, Aligned, _)>` to a
`Ptr<T, (_, Unaligned, _)>`.

The problem with this approach is that validity doesn't just specify
what bit patterns can be expected to be read from a `Ptr`'s referent, it
also specifies what bit patterns are permitted to be *written* to the
referent. Thus, "forgetting" about validity and expanding the set of
expected bit patterns also expands the set of bit patterns which can be
written.

Consider, for example, "forgetting" that a `Ptr<bool, (_, _, Valid)>` is
bit-valid, and downgrading it to a `Ptr<bool, (_, _, Initialized)>`. If
the aliasing is `Exclusive`, then the resulting `Ptr` would permit
writing arbitrary `u8`s to the referent, violating the bit validity of
the `bool`.

This commit moves us in the direction of a new model, in which changes
to the referent type or the validity of a `Ptr` must abide by the
following rules:
- If the resulting `Ptr` permits mutation of its referent (either via
  interior mutation or `Exclusive` aliasing), then the set of allowed
  bit patterns in the referent may not expand
- If the original `Ptr` permits mutation of its referent while the
  resulting `Ptr` is also live (i.e., via interior mutation on a
  `Shared` `Ptr`), then the set of allowed bit patterns in the referent
  may not shrink

This commit does not fix `transparent_wrapper_into_inner`, which will
require an overhaul or replacement of the `TransparentWrapper` trait.

Makes progress on #2226, #1866


gherrit-pr-id: I95d6c5cd23eb5ea6629cd6e4b99696913b1ded93

Co-authored-by: Jack Wrenn <jswrenn@amazon.com>

Since we currently can't roll our pinned nightly toolchain, and since
support for the avr target which initially caused us to notice this
issue was only added on nightly recently, this commit does not add a
regression test. That will be done later as part of #2400 once we are
able to roll our pinned nightly toolchain.

Makes progress on #2400

gherrit-pr-id: I2ce6e9e0c2ba1cbe24c8cc5686e5b9b519bbf102