Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Passing in the declared interface type to checkConformance() here
masked a silent failure where if the type declaration was generic
and the conformance conditional, the conditional requirement check
would fail. As a result, we did not diagnose the absence of
@retroactive, nor the unnecessary presence of it.
Since we only care about the existence of some conformance, we
can use lookupConformance() instead.
When the BitwiseCopyable experimental feature is enabled, infer types to
conform to `_BitwiseCopyable`. The `_BitwiseCopyable` inference broadly
follows the approach taken to infer `Sendable`.
(1) Special types are conformed:
- function types if trivial
- metatypes
- builtin types if trivial
(2) TheTupleType is conditionally conformed.
(3) Nominal types are conformed if:
- non-public or public+fixed-layout
- enum or struct (non-class)
- every field conforms to _BitwiseCopyable
Additionally, check that nominal types which are explicitly conformed to
`_BitwiseCopyable` satisfy the latter two conditions of (3).
For a public, non-fixed-layout type to conform to `_BitwiseCopyable`,
the user must conform the type explicitly.
Finally, verify that conformances correspond to TypeLowering's notion of
triviality to the appropriate extent:
- if a type isn't trivial, it doesn't conform to `_BitwiseCopyable`
unless it's an archetype
- if a type is trivial, it conforms to `_BitwiseCopyable` unless some
field in its layout doesn't conform to `_BitwiseCopyable`, which is
only permitted under certain circumstances (the type has generic
parameters, the type is public non-fixed-layout, the type is a
reference but has ReferenceStorage::Unmanaged, the type is a
ModuleType, etc.)
Besides being an optimization, using memcpy directly rather than a value
witness is required in order to interact with unaligned instances of
such types: the value witness functions expect their arguments to be
aligned.
rdar://96919870
