Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
It's done by first retrieving all generic parameters from each solution,
filtering boundings into distrinct set and diagnosing any differences.
For example:
```swift
func foo<T>(_: T, _: T) {}
func bar(x: Int, y: Float) {
foo(x, y)
}
```
* diagnostic when a closure parameter is declared with type sugar
* Use a test that was already commmited for SR-11724
i
* Use isa<T> instead of asking for the kind directly
* Fix nit: Remove a whitespace
This commit changes how we represent caller-side
default arguments within the AST. Instead of
directly inserting them into the call-site, use
a DefaultArgumentExpr to refer to them indirectly.
The main goal of this change is to make it such
that the expression type-checker no longer cares
about the difference between caller-side and
callee-side default arguments. In particular, it
no longer cares about whether a caller-side
default argument is well-formed when type-checking
an apply. This is important because any
conversions introduced by the default argument
shouldn't affect the score of the resulting
solution.
Instead, caller-side defaults are now lazily
type-checked when we want to emit them in SILGen.
This is done through introducing a request, and
adjusting the logic in SILGen to be more lenient
with ErrorExprs. Caller-side defaults in primary
files are still also currently checked as a part
of the declaration by `checkDefaultArguments`.
Resolves SR-11085.
Resolves rdar://problem/56144412.
It was being used purely to get the name of the type context for a diagnostic
message. SourceKit's syntactic-only requests were hitting an assertion when
this diagnostic was triggered because they don't set up a type checker.
When SE-110 was being implemented, we accidentally began to accept
closure parameter declarations that had no associated parameter names,
e.g.
foo { ([Int]) in /**/ }
This syntax has never been sanctioned by any version of Swift and should
be banned. However, the change was made long enough ago and there are
enough clients relying on this, that we cannot accept the source break
at the moment. For now, add a bit to ParamDecl that marks a parameter
as destructured, and back out setting the invalid bit on the type repr
for these kinds of declarations.
To prevent further spread of this syntax, stub in a warning that offers
to insert an anonymous parameter.
Resolves part of rdar://56673657 and improves QoI for errors like
rdar://56911630
When it comes to `@autoclosure` parameters we only detect and diagnose
mismatches related to invalid implicit conversions to pointer types. But
`@autoclosure` parameters just like regular ones can have type mismatches
as well which can be handled via recently introduced
`argument-to-parameter mismatch` fix.
We could actually allow this for local functions, but it's not
worth implementing that until the more general ability of local
function default arguments to capture values is implemented.
Fixes <rdar://problem/55119566>.
If the only difference between two functions is `throws` and it
is not a subtype relationship, let's repair the problem by dropping
`throws` attribute and letting solver continue to search for
a solution, which would later be diagnosed.
Introduce a fix to detect and diagnose situations when omitted
generic arguments couldn't be deduced by the solver based on
the enclosing context.
Example:
```swift
struct S<T> {
}
_ = S() // There is not enough context to deduce `T`
```
Resolves: rdar://problem/51203824
