A generic signature's `getInnermostGenericParams` will find the generic
parameters in the innermost scope. That's not quite right for printing
inverses, since we don't want to print an inverse for `T` when emitting
the generic signature of `f` below:
```swift
struct S<T: ~Copyable, E> {
func f() where E == Never {}
}
```
Since `f` has its own generic signature, but doesn't define any generic
parameters, it shouldn't have an inverse emitted. The solution here is
to filter inverses by depth of the generic parameter.
We also want to print _all_ of the inverses in other situations, rather
than just the innermost ones. This aids in debugging and other
tools like the API digester.
resolves rdar://130179698
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
Member operators of concrete nominal types must declare at least
one parameter with that type, like
```
struct S {
static func +(lhs: S, rhs: Int) -> S {}
}
```
For protocol member operators, we would look for a parameter of type
`Self`, or an existential type `any P`. While the latter was
consistent with the concrete nominal type case, it was actually
wrong because then the resulting interface type does not give the
type checker any way to bind the `Self` type parameter.
There were two existing test cases that now produce errors, which I
believe is now correct. While this is technically a source break,
because these bogus operators seemingly cannot be witnessed or called,
such a protocol probably had no conforming types.
Fixes https://github.com/apple/swift/issues/73201.
The presence of Copyable/Escapable conformances doesn't affect ABI. Only
their absence in terms of suppressed requirements like `~Copyable` need
to be output for diffing by the APIDigester.
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.)
There is a small bug fix here in the identification of the catch node,
where the leading `{` of a closure was considered to be "inside" the
closure for code like
{ ... }()
causing us to assume that the call to the closure would catch the error
within the closure.
Other than that, introduce the thrown error type into the type checker's
modeling of `withoutActuallyEscaping(_:do:)`, and mirror that in the
library declaration.
Make `init(catching:)` and `get()` use typed throws. The former infers
the `Failure` type from the closure provided (once full type inference
is in place) and the latter only throws errors of the `Failure` type.
In theory this is a source break if someone had a weird custom
conforming type, but I suspect in practice conformances to
this protocol are never defined.
The reason we want this requirement is that often you will see
code like the following:
protocol Point {
associatedtype Scalar: SIMDScalar
associatedtype Vector: SIMD where Vector.Scalar == Scalar
}
extension Point where Vector == SIMD2<Scalar> { ... }
When `Vector` is equated with `SIMD2<Scalar>`, we get an infinite
sequence of implied same-type requirements:
Vector.MaskStorage == SIMD2<Scalar.MaskScalar>
Vector.MaskStorage.MaskStorage == SIMD2<Scalar.MaskScalar.MaskScalar>
...
The protocol fails to typecheck with an error because the requirement
machine cannot build a rewrite system.
If SIMDScalar requires that MaskScalar.MaskScalar == MaskScalar, then
we instead get
Vector.MaskStorage == SIMD2<Scalar.MaskScalar>
Vector.MaskStorage.MaskStorage == SIMD2<Scalar.MaskScalar>
Vector.MaskStorage.MaskStorage == Vector.MaskStorage
...
Which ties off the recursion.
In theory, a more advanced implementation could represent this kind of
infinite recursion in 'closed form', but we don't have that yet, and I
believe adding this same-type requirement makes sense anyway.
Fixes rdar://problem/95075552.
Unfortunately, we can't make this optimization work internally for now.
However, we can revisit it later. One strategy would be to emit the
witness as a private declaration, so that clients call it through the
witness table.
Fixes rdar://problem/86861522.
The first generic parameter of an `OpaqueTypeDecl` was still being used
as the "underlying" interface type of the opaque type, which is
incorrect for both structural and named opaque result types. Eliminate
this notion, because the (declared) interface type already has the
correct structure.
Only ABI checking depended on the old "underlying" type, so rework it to
instead substitute into properly for structural opaque result types as
well.
Deserialization required a small adjustment to eliminate a cycle
because the interface type of an `OpaqueTypeDecl` involves opaque
archetype types, which reference the declaration itself... so
deserialize the interface type later, now that it's correct.
