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
Type inside of an editor placeholder is more of a hint than anything else,
so if it's incorrect let's diagnose that and use type variable instead to
allow solver to make forward progress.
Resolves: SR-14213
Resolves: rdar://74356736
If argument is a floating-point literal, with newly introduced implicit
Double<->CGFloat conversion, sometimes it's better to choose a concrete
function/operator overload on `CGFloat` even if it's not a default literal
type e.g. `let _: CGFloat = min(1.0, log(<CGFloat value>))` shouldn't form
solutions with `Double` arguments since it would result in multiple
implicit conversions, it's better to use a `CGFloat` type for the arguments.
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.
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.
property wrapper custom attribute to get the backing wrapper type
in CSApply.
This is necessary because implicit custom attributes do not have
TypeReprs, but they always have TypeExprs.
Move markAcceptableDiscardExprs into PreCheckExpr so that we can perform this analysis before we convert expressions like `_? = <value>` into `_ = <value>` since `_?` is now an expression with meaning, and we only want to perform this transformation when `_?` is on the LHS of an assignment
Rename `openUnboundGenericTypes` to `convertInferableTypes`. In addition to unbound generics, this method also converts placeholder types to fresh type variables.
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.
* Initial draft of async sequences
* Adjust AsyncSequence associated type requirements
* Add a draft implementation of AsyncSequence and associated functionality
* Correct merge damage and rename from GeneratorProtocol to AsyncIteratorProtocol
* Add AsyncSequence types to the cmake lists
* Add cancellation support
* [DRAFT] Implementation of protocol conformance rethrowing
* Account for ASTVerifier passes to ensure throwing and by conformance rethrowing verifies appropriately
* Remove commented out code
* OtherConstructorDeclRefExpr can also be a source of a rethrowing kind function
* Re-order the checkApply logic to account for existing throwing calculations better
* Extract rethrowing calculation into smaller functions
* Allow for closures and protocol conformances to contribute to throwing
* Add unit tests for conformance based rethrowing
* Restrict rethrowing requirements to only protocols marked with @rethrows
* Correct logic for gating of `@rethrows` and adjust the determinates to be based upon throws and not rethrows spelling
* Attempt to unify the async sequence features together
* Reorder try await to latest syntax
* revert back to the inout diagnosis
* House mutations in local scope
* Revert "House mutations in local scope"
This reverts commit d91f1b25b59fff8e4be107c808895ff3f293b394.
* Adjust for inout diagnostics and fall back to original mutation strategy
* Convert async flag to source locations and add initial try support to for await in syntax
* Fix case typo of MinMax.swift
* Adjust rethrowing tests to account for changes associated with @rethrows
* Allow parsing and diagnostics associated with try applied to for await in syntax
* Correct the code-completion for @rethrows
* Additional corrections for the code-completion for @rethrows this time for the last in the list
* Handle throwing cases of iteration of async sequences
* restore building XCTest
* First wave of feedback fixes
* Rework constraints checking for async sequence for-try-await-in checking
* Allow testing of for-await-in parsing and silgen testing and add unit tests for both
* Remove async sequence operators for now
* Back out cancellation of AsyncIteratorProtocols
* Restructure protocol conformance throws checking and cache results
* remove some stray whitespaces
* Correct some merge damage
* Ensure the throwing determinate for applying for-await-in always has a valid value and adjust the for-await-in silgen test to reflect the cancel changes
* Squelch the python linter for line length
for arithmetic operators.
Only sort overloads that are related, e.g. Sequence
overloads. Further, choose which generic overloads
to attempt first based on whether any known argument types
conform to one of the standard arithmetic protocols.
