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
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.
These were defined for both FixedWidthInteger and FixedWidthInteger & SignedInteger for source compatibility with Swift 3; the latter set probably should have been removed when we stabilized the ABI, but were not. We can't easily remove them entirely (because we need them for ABI stability now), but we can mark them unavailable so that the typechecker doesn't have to consider them..
Make both Error and CodingKey conform to ConcurrentValue, so that
thrown errors always conform to ConcurrentValue. Downgrade (to
warnings) and ConcurrentValue-related diagnostics that are triggered
by this change in existing Error and CodingKey-conforming types to
reduce the impact on source compatibility.
Most of this is enabled by an upstream change to generalize the tests
for the api-digester to properly handle all targets. The primary change
here is to account for the Swift-level ABI differences for the standard
library between Apple Silicon macOS and Intel macOS. Specifically, anything
related to Float80 will be removed from the standard library on Apple Silicon
macOS, so account for the differences.
