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
While it is very convenient to default the ExtInfo state when creating
new function types, it also make the intent unclear to those looking to
extend ExtInfo state. For example, did a given call site intend to have
the default ExtInfo state or does it just happen to work? This matters a
lot because function types are regularly unpacked and rebuilt and it's
really easy to accidentally drop ExtInfo state.
By changing the ExtInfo state to an optional, we can track when it is
actually needed.
The existing overloading rules strongly prefer async functions within
async contexts, and synchronous functions in synchronous contexts.
However, when there are other differences in the
signature, particularly parameters of function type that differ in
async vs. synchronous, the overloading rule would force the use of the
synchronous function even in cases where the synchronous function
would be better. An example:
func f(_: (Int) -> Int) { }
func f(_: (Int) async -> Int) async { }
func g(_ x: Int) -> Int { -x }
func h() async {
f(g) // currently selects async f, want to select synchronous f
}
Effect the semantics change by splitting the "sync/async mismatch"
score in the constraint system into an "async in sync mismatch" score
that is mostly disqualifying (because the call will always fail) and a
less-important score for "sync used in an async context", which also
includes conversion from a synchronous function to an asynchronous
one. This way, only synchronous functions are still considered within
a synchronous context, but we get more natural overloading behavior
within an asynchronous context. The end result is intended to be
equivalent to what one would get with reasync:
func f(_: (Int) async -> Int) async { ... }
Addresses rdar://74289867.
Currently bindings where inferred on every `bindTypeVariable` call,
but that's wasteful because not all binds are always correct. To
avoid unnecessary inference traffic let's wait until re-activated
constraints are simplified and notify binding inference about new
fixed type only if all of them are successful.
when it has property wrapper parameters.
The property wrapper type will be replaced with either the wrapped-value
or projected-value type, depending on the argument label/parameter name,
and CSApply will build a thunk to construct the property wrapper and call
the function.
`PotentialBindings` lost most of its responsibilities,
and are no longer comparable. Their main purpose now
is binding and metadata tracking (introduction/retraction).
New `BindingSet` type is something that represents a set
of bindings at the current step of the solver.
Instead of requiring result type of the member to conform to declaring protocol,
as originally proposed by SE-0299, let's instead require `Self` to be bound to
some concrete type in extension that declares a static member.
This would make sure that:
1. Members are only visible on a particular type;
2. There is no ambiguity regarding what base of the member chain is going to be.
Produce a tailored diagnostic when it has been established that
base type of a static member reference on protocol metatype doesn't
conform to a required protocol.
Since it's now possible to refer to static members declared on a protocol
metatype if result type conforms to the protocol we need to adjust failure
detection to identify that conformance failure means and invalid reference
in certain situations.
Rename `openUnboundGenericTypes` to `convertInferableTypes`. In addition to unbound generics, this method also converts placeholder types to fresh type variables.
The isGetterMutating() and isSetterMutating() checks already return
false if the storage is a static property or defined on a reference
type, so the isStatic() and hasReferenceSemantics() checks were not
needed.
SILGen verification crash when no other async functions are called in a function body not marked as async when a for-await-in syntax is used. This corrects the diagnostics to ensure that the type check effects sees the proper async call that the for-await-in syntax infers.
for-await-in syntax was missing a diagnistic hint for inserting a try when the protocol conformance of the sequence shows a potential of throwing. (also there was a superfluous check for the nominal type in that type check (which was removed).
for-await-in syntax and for-try-await-in syntax did not infer async or throwing to closure constraints, both were added to properly identify the asyncy-ness/throwy-ness of the iteration.
Currently the pattern is to collect the type variables and then unique
them. Instead of asking clients to do uniquing, let's just accept a set
as an argument.
