When a function’s completion handler is being passed to another function and the function that the completion handler is being declared in is converted to async, replace the call to the completion handler by a `return` statement.
For example:
```swift
func foo(completion: (String) -> Void) {
bar(completion)
}
```
becomes
```swift
func foo() async -> String {
return await bar()
}
```
Previously, we were calling the completion handler, which no longer exists in the newly created `async` function.
In overloaded context it's possible that there is an overload that
expects a closure but it can have other issues e.g. different number
of parameters, so in order to pick a better solution let's always
increase a score for overloads where closure is matched against a
non-function type parameter.
getParsedMembers() on imported and deserialized contexts has to pull
in all the members. This is wasteful. Imported contexts do not have
fingerprints at all, and fingerprints of deserialized contexts are
serialized separately.
The fast path handles these cases, only calling down to
getParsedMembers() if the parent FileUnit is a SourceFile.
This commit changes JobFlags storage to be 32bits, but leaves the runtime
API expressed in terms of size_t. This allows us to pack an Id in the
32bits we freed up.
The offset of this Id in the AsyncTask is an ABI constant. This way
introspection tools can extract the currently running task identifier
without any need for special APIs.
Previously, we only supported refactoring a function to call the async alternative if a closure was used for the callback parameter. With this change, we also support calling a arbitrary function (or variable with function type) that is passed to the completion handler argument.
The implementation basically re-uses the code we already have to create the legacy function’s body (which calls the newly created async version and then forwards the arguments to the legacy completion handler).
To describe the completion handler that the result is being forwarded to, I’m also using `AsyncHandlerDesc`, but since the completion handler may be a variable, it doesn’t necessarily have an `Index` within a function decl that declares it. Because of this, I split the `AsyncHandlerDesc` up into a context-free `AsyncHandlerDesc` (without an `Index`) and `AsyncHandlerParamDesc` (which includes the `Index`). It turns out that `AsyncHandlerDesc` is sufficient in most places.
Resolves rdar://77460524
Disable non-Optional "assumption" warning for ambiguities related to a
static member lookup in generic context because it's possible to declare
a member with the same name on a concrete type and in an extension of a
protocol that type conforms to e.g.:
```swift
struct S : P { static var test: S { ... }
extension P where Self == S { static var test: { ... } }
```
And use that in an optional context e.g. passing `.test`
to a parameter of expecting `S?`.
Resolves: rdar://77700261
Remove the `TypeCheckExprFlags::AllowUnresolvedTypeVariables` flag, fixing another occurance of rdar://76686564 (https://github.com/apple/swift/pull/37309)
This does not break anything in the test suite, so I think the removal of the flag is fine.
Resolves rdar://76686564 and rdar://77659417
Not all of the pre-check errors could be diagnosed by re-running
`PreCheckExpression` e.g. key path expressions are mutated to
a particular form after an error has been produced.
To make the behavior consistent, let's allow pre-check to emit
diagnostics and unify pre-check and constraint generation fixes.
Resolves: rdar://77466241
For example, non-Darwin platforms probably don't want
`#colorLiteral(red:green:blue":alpha:)` and `#imageLiteral(named:)`.
Add an completion option to include them, which is "on" by default.
rdar://75620636
Boxes tend to have a small number of uses, so frequently finding the
unique projection isn't too bad. Non-boxes, however, can have a large
number of uses: for example, a class instance has expected uses
proportionate to the number of stored properties. So if we do a linear
scan of the uses on a non-box instruction, we'll scale quadratically.
Fixes SR-14532.
Consider a signature with a conformance requirement, and two
identical superclass requirements, both of which make the
conformance requirement redundant.
The conformance will have two requirement sources, the explicit
source and a derived source based on one of the two superclass
requirements, whichever one was processed first.
If we end up marking the *other* superclass requirement as
redundant, we would incorrectly conclude that the conformance
was not redundant. Instead, if a derived source is based on a
redundant requirement, we can't just discard it right away;
instead, we have to check if that source could have been
derived some other way.
This used to be necessary to handle this case:
protocol P1 {
associatedtype A
}
protocol P2 {
associatedtype A : P1
}
func foo<T : P1>(_: T) where T.A : P2, T.A.A == T {}
We don't want to mark 'T : P1' as redundant, even though it could
be recovered from T.A.A, because it uses the requirement T.A, and
we cannot recover the type metadata for T.A without the witness
table for T : P1.
Now this is handled via a more general mechanism, so we no longer
need this hack.
Consider this example:
protocol P1 {
associatedtype A : P2
}
protocol P2 {
associatedtype A
}
func foo<T : P2>(_: T) where T.A : P1, T.A.A == T {}
We cannot drop 'T : P2', even though it can be derived from
T.A.A == T and Self.A : P2 in protocol P1, because we actually
need the conformance T : P2 in order to recover the concrete
type for T.A.
This was handled via a hack which would ensure that the
conformance path (T.A : P1)(Self.A : P2) was not a candidate
derivation for T : P2, because T : P2 is one of the conformances
used to construct the subject type T.A in the conformance path.
This hack did not generalize to "cycles" of length greater than 1
however:
func foo<T : P2, U : P2>(_: T, _: U)
where T.A : P1, T.A.A == U, U.A : P1, U.A.A == T {}
We used to drop both T : P2 and U : P2, because each one had a
conformance path (U.A : P1)(Self.A : P2) and (T.A : P1)(Self.A : P2),
respectively; however, once we drop T : P2 and U : P2, these two
paths become invalid for the same reason that the concrete type
for T.A and U.A can no longer be recovered.
The correct fix is to recursively visit the subject type of each
base requirement when evaluating a conformance path, and not
consider any requirement whose subject type's parent type cannot
be recovered. This proceeds recursively.
In the worst case, this algorithm is exponential in the number of
conformance requirements, but it is not always exponential, and
a generic signature is not going to have a large number of
conformance requirements anyway (hopefully). Also, the old logic
in getMinimalConformanceSource() wasn't cheap either.
Perhaps some clever minimization can speed this up too, but I'm
going to focus on correctness first, before looking at performance
here.
Fixes rdar://problem/74890907.
Literally an off-by-one error -- we were skipping over the first
requirement and not copying it over. I think this is because the
updateLayout() call used to be addLayoutRequirementDirect(),
which would add the first layout constraint, and I forgot to
remove the '+ 1' when I refactored this.
This fixes a regression from the new redundant requirements algorithm
and paves the way for removing the notion of 'derived via concrete'
requirements.
This rewrites the existing redundant requirements algorithm
to be simpler, and fix an incorrect behavior in the case where
we're building a protocol requirement signature.
Consider the following example:
protocol P {
associatedtype A : P
associatedtype B : P where A.B == B
}
The requirement B : P has two conformance paths here:
(B : P)
(A : P)(B : P)
The naive redundancy algorithm would conclude that (B : P) is
redundant because it can be derived as (A : P)(B : P). However,
if we drop (B : P), we lose the derived conformance path
as well, since it involves the same requirement (B : P).
The above example actually worked before this change, because we
handled this case in getMinimalConformanceSource() by dropping any
derived conformance paths that involve the requirement itself
appearing in the "middle" of the path.
However, this is insufficient because you can have a "cycle"
here with length more than 1. For example,
protocol P {
associatedtype A : P where A == B.C
associatedtype B : P where B == A.C
associatedtype C : P where C == A.B
}
The requirement A : P has two conformance paths here:
(A : P)
(B : P)(C : P)
Similarly, B : P has these two paths:
(B : P)
(A : P)(C : P)
And C : P has these two paths:
(C : P)
(A : P)(B : P)
Since each one of A : P, B : P and C : P has a derived conformance
path that does not involve itself, we would conclude that all three
were redundant. But this was wrong; while (B : P)(C : P) is a valid
derived path for A : P that allows us to drop A : P, once we commit to
dropping A : P, we can no longer use the other derived paths
(A : P)(C : P) for B : P, and (A : P)(B : P) for C : P, respectively,
because they involve A : P, which we dropped.
The problem is that we were losing information here. The explicit
requirement A : P can be derived as (B : P)(C : P), but we would
just say that it was implied by B : P alone.
For non-protocol generic signatures, just looking at the root is
still sufficient.
However, when building a requirement signature of a self-recursive
protocol, instead of looking at the root explicit requirement only,
we need to look at _all_ intermediate steps in the path that involve
the same protocol.
This is implemented in a new getBaseRequirements() method, which
generalizes the operation of getting the explicit requirement at
the root of a derived conformance path by returning a vector of
one or more explicit requirements that appear in the path.
Also the new algorithm computes redundancy online instead of building
a directed graph and then computing SCCs. This is possible by
recording newly-discovered redundant requirements immediately,
and then using the set of so-far-redundant requirements when
evaluating a path.
This commit introduces a small regression in an existing test case
involving a protocol with a 'derived via concrete' requirement.
Subsequent commits in this PR fix the regression and remove the
'derived via concrete' mechanism, since it is no longer necessary.
Fixes https://bugs.swift.org/browse/SR-14510 / rdar://problem/76883924.
