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.
Previously, we use USR as a delegate for mangled name. However, USR won't incorporate name changes made
by attributes like @_silgen_name. Instead, we should add a dedicated field for canonical mangled names.
rdar://84202064
Previously, we use USR as a delegate for mangled name. However, USR won't incorporate name changes made
by attributes like @_silgen_name. Instead, we should add a dedicated field for canonical mangled names.
rdar://84202064
Moving generic constraint from extension to its member or vice versa may change the mangled name
of the member without changing the generic signature, thus introducing ABI breakages. This change
teaches the ABI checker to diagnose USR (mangled name) changes to cover such cases.
rdar://78276290
Before this change, the ABI checker didn't complain about missing @available
attributes on new APIs if the enclosing scopes of new APIs have
availability information. Instead, we should require explicit @available attributes
for new APIs to prevent them inheriting wrong availability information from a
preexisting scope.
rdar://81719628
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.
When referring to an actor-isolated declaration from outside of the
actor, ensure that the types involved conform to the `ConcurrentValue`
protocol. Otherwise, produce a diagnostic stating that it is unsafe to
pass such types across actors.
Apply the same rule to local captures within concurrent code.
Removing or updating @_alwaysEmitIntoClient functions are never ABI-breaking, thus
we should exclude them from the symbol set for ABI stability checking.
rdar://67883661
