Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
Remove the default argument for the `memberType`
parameter and enforce that GenericFunctionType is
not passed. Also add a defaulted overload for the
property case, as they should never have a
GenericFunctionType interface type.
If solutions either have no fixes at all or all of the are warnings,
let's use `diagnoseAmbiguity` to diagnose such cases as-if there are
no fixes at all.
Resolves: rdar://79657350
AutoClosureExprs created by the constraint system used to be constructed
with the decl context of the constraint system itself. This meant that
autoclosures in expressions nested in closures would initially be
parented onto any enclosing functions rather than the deepest closure
context. When we ran capture analysis and lookup from inside of the body
of these nascent values, we would fail to find declarations brought into
scope by those parent closures. This is especially relevant when
pre-typechecked code is involved since captures for those declarations
will be forced before their bodies have been recontextualized. See
issue #34230 for why we need to force things so early.
The attached test case demonstrates both bugs: The former a bogus lookup
through the parent context that would incorrectly reject this otherwise
well-formed code. The latter is a crash in SILGen when the capture
computation would fail to note $0.
Use the decl context of the solution application target, which is always
going to be the deepest user-written closure expression available to us,
and therefore the deepest scope that can introduce capturable variables.
rdar://79248469
This commit essentially consistes of the following steps:
- Add a new code completion key path component that represents the code completion token inside a key path. Previously, the key path would have an invalid component at the end if it contained a code completion token.
- When type checking the key path, model the code completion token’s result type by a new type variable that is unrelated to the previous components (because the code completion token might resolve to anything).
- Since the code completion token is now properly modelled in the constraint system, we can use the solver based code completion implementation and inspect any solution determined by the constraint solver. The base type for code completion is now the result type of the key path component that preceeds the code completion component.
This resolves bugs where code completion was not working correctly if the key path’s type had a generic base or result type. It’s also nice to have moved another completion type over to the solver-based implementation.
Resolves rdar://78779234 [SR-14685] and rdar://78779335 [SR-14703]
Currently ambiguity notes attached to a candidate only mention
expected type and its position. To improve clarify of such notes
it's useful to print argument type as well since it's not always
clear what it is at the first glance at the code.
Resolves: SR-14634
Resolves: rdar://78224323
Abstract away the TupleExpr gunk and expose
`getLHS` and `getRHS` accessors. This is in
preparation for completely expunging the use
of TupleExpr as an argument list.
This saves us from needing to re-match args to params in CSApply and is also
useful for a forthcoming change migrating code completion in argument position
to use the solver-based typeCheckForCodeCompletion api.
rdar://76581093
When referencing a function that is on a global actor, e.g.,
@MainActor func doSomething() -> Int
the result of that reference is a global-actor-qualified function type, e.g.,
@MainActor () -> Int
Part of rdar://76030136.
This fixes a performance regression with the reasync '&&', '||' and '??'
operators.
Also arguably it makes sense anyway since 'reasync' functions can in
fact be called from synchronous functions, so the solution should not
be considered worse.
We don't actually want to be able to overload a synchronous function
with a 'reasync' function anyway; the whole point of 'reasync' is to
avoid the need for such overloading.
Fixes rdar://problem/76254445.
If have a function that takes a trailing closure as follows
```
func sort(callback: (_ left: Int, _ right: Int) -> Bool) {}
```
completing a call to `sort` and expanding the trailing closure results in
```
sort { <#Int#>, <#Int#> in
<#code#>
}
```
We should be doing a better job here and defaulting the trailing closure's to the internal names specified in the function signature. I.e. the final result should be
```
sort { left, right in
<#code#>
}
```
This commit does exactly that.
Firstly, it keeps track of the closure's internal names (as specified in the declaration of `sort`) in the closure's type through a new `InternalLabel` property in `AnyFunctionType::Param`. Once the type containing the parameter gets canonicalized, the internal label is dropped.
Secondly, it adds a new option to `ASTPrinter` to always try and print parameter labels. With this option set to true, it will always print external paramter labels and, if they are present, print the internal parameter label as `_ <internalLabel>`.
Finally, we can use this new printing mode to print the trailing closure’s type as
```
<#T##callback: (Int, Int) -> Bool##(_ left: Int, _ right: Int) -> Bool#>
```
This is already correctly expanded by code-expand to the desired result. I also added a test case for that behaviour.
Currently inference logic only checked direct equivalence class members
associated with a "work-in-progress" type variable, but each member can
have local equivalences as well that need to be accounted for.
Resolves: rdar://75978086
Add logic to `matchTypes` to insert an implicit conversion to/from
CGFloat type when two nominal types are matched and one of them is
of `CGFloat` type.
Currently `getFunctionArgApplyInfo` expects a locator with `ApplyArgToParam`
element to identify location of the argument. `InOutExpr` could only be used
in argument positions but it doesn't have the same locator format as non-inout
arguments, so `getFunctionArgApplyInfo` needs to do some digging in the AST
to retrieve that information.
Resolves: rdar://75146811
