Such implicit tuples may be used to represent
argument lists for e.g binary expressions, and as
such shouldn't be considered as parent exprs that
satisfy the role of parentheses.
Also fix the callers to use the raw anchor as the
root expression they pass to provide an accurate
parent map. This requires sinking the
UnresolvedMemberChainResultExpr handling logic into
`getPrecedenceParentAndIndex`.
rdar://81109287
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.
Parse and provide semantic checking for '@unchecked Sendable', for a
Sendable conformance that doesn't perform additional semantic checks
for correctness.
Part of rdar://78269000.
The `equals_lower` API was replaced with `equals_insensitive` in llvm
commit 2e4a2b8430aca6f7aef8100a5ff81ca0328d03f9 and
3eed57e7ef7da5eda765ccc19fd26fb8dfcd8d41.
Ran git clang-format.
(cherry picked from commit e21e70a6bf)
Layout requirement doesn't have a second type since it's always `AnyObject`,
requirement failure note should handle that, otherwise in no assertion builds
this would crash in diagnostic engine trying to emit the note.
Resolves: rdar://79672230
type to the locator.
This will provide context for tuple element mismatch diagnostics, instead
of attempting to compute the full tuple type in diagnostics code with a pile
of special cases (see getStructuralTypeContext in CSFix.cpp).
For checked cast coercion warnings let's store difference in optionality
as an `int` because it's possible that "to" type is more optional than
"from" type.
Before suggesting to add `where Self == ...` condition to the extension
of a protocol involved in a static member lookup, let's check whether
type repr is available and valid.
Resolves: rdar://78097387
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.
If `async` effect has been inferred from the body of the closure,
let's find out the first occurrence of `async` node and point it out
to make it clear why closure is `async`.
Resolves: rdar://70610141
`ContextualFailure` is the main beneficiary of additional information
associated with `ContextualType` element because it no longer has to
query solution for "purpose" of the contextual information.
Resolves: rdar://68795727
Having purpose attached to the contextual type element makes it much
easier to diagnose contextual mismatches without involving constraint
system state.
If there is a contextual mismatch associated with a closure body,
make sure that the diagnostic is attached to the closure even
if the body is empty or implicit.
Resolves: rdar://52204608
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.
If closure parameter has an explicit type, type resolution
would diagnose the issue and cache the resulting error type for
future use. Invalid types currently fail constraint generation,
which doesn't play well with result builders because constraint
generation for their bodies happens during solving.
Let's handle invalid parameters gracefully, replace them with
placeholders and let constraint generation proceed.
Resolves: rdar://75409111
