There are conformers to SIMDStorage (like that in the added test case)
which involve an Array (a type that can't conform to BitwiseCopyable).
So lift the constraint on SIMDStorage. This in turn requires lifting
the constraint on SIMD (otherwise, e.g. `SIMD8<Scalar>` would fail to
conform since it has as a member some SIMD8Storage which is only
constrained to conform to `SIMDStorage`; the `SIMD8Storage`
associatedtype also cannot be constrained to `BitwiseCopyable` because
that storage may again not conform as in the test example).
rdar://128661878
The standard library defines
```
protocol BitwiseCopyable {}
typealias _BitwiseCopyable = BitwiseCopyable
```
For current compilers, `BitwiseCopyable` is a "known protocol".
For older compilers, it is not; instead `_BitwiseCopyable` is. So
print the following into the swiftinterface for those older compilers:
```
protocol _BitwiseCopyable {}
typealias BitwiseCopyable = _BitwiseCopyable
```
rdar://127755503
This means that they can't use _Int128 for their implementation, but efficient implementation of these using only 64b arithmetic is pretty straightforward, so that's OK. This allows them to be specialized and mostly optimized away in release builds.
The copy operator has been implemented and doesn't use it. Remove
`Builtin.copy` and `_copy` as much as currently possible.
Source compatibility requires that `_copy` remain in the stdlib. It is
deprecated here and just uses the copy operator.
Handling old swiftinterfaces requires that `Builtin.copy` be defined.
Redefine it here as a passthrough--SILGen machinery will produce the
necessary copy_addr.
rdar://127502242
I accidentally copy and pasted the mangled symbol names in the wrong order, so existing callers got directed to the wrong entry points, and things got terribly, terribly wrong.
(We badly need a sensible replacement for these `@_silgen_name` hacks.)
Huge thanks to @edymtt for spotting this!
rdar://127016847
There were two categories of problem for older compilers that consume the
stdlib `.swiftinterface`:
- The `case .some(borrowing x)` syntax isn't accepted; use `_borrowing`
- Various functions that addopted `~Copyable` generic constraints conflict with
the `@usableFromInline` ABI stubs that were left in to preserve compatibility
when the functions are printed with `~Copyable` constraints stripped. The stubs
need to have different names to get out of the way.
Resolves rdar://127132742
The layout of a computed key path component carries an argument buffer for captures, which has
the following layout:
```
---
captured values (subscript indices)
---
generic arguments
---
```
When we reference an externally-defined public property or subscript from a key path, and the
external declaration has a property descriptor, then the generic arguments for the external
declaration get appended to the end of this buffer, giving:
```
---
captured values (subscript indices)
---
generic arguments
---
external property's generic arguments
---
```
The convention for key path accessors to bind their generic environment is thus to unpack them
from the end of the argument buffer, so that the external keypath's accessors can find the
arguments to bind the external generic environment while still allowing the enclosing key path
to save the original captured generic environment (which may be necessary to capture the
appropriate conditional and/or retroactive `Equatable` and `Hashable` conformances for
subscript indices).
However, our code generation for binding the generic arguments out of the argument buffer
contained a flawed optimization: for a property, we know there are never any captured values,
so I had assumed that the generic parameters could always be bound from the beginning of the
argument buffer, assuming that the generic parameters make up the totality of the buffer. This
falls over for external property descriptor references when the key path itself captures a
generic environment, since the external property's expected generic environment appears after
the key path's original generic environment. We can fix this by removing the conditional
entirely, and always adjusting the offset we load the generic environment from to look at the
end of the buffer. Fixes rdar://125886333.
This protocol appears in the stdlib as scaffolding for the
`NonescapableTypes` feature, which is still experimental and not gone
through evolution as an approved addition to the stdlib.
Rather than delete it from the stdlib, because it needs to still remain
to support that feature work, gate references to it behind a feature
flag.
Additionally, prevent documentation from seeing this declaration.
rdar://126705184
