This new attribute can be used on parameters of `@Sendable async` type
to indicate that the closures arguments passed to such parameters
should inherit the actor context where they are formed, which is not
the normal behavior for `@Sendable` closures.
Another part of rdar://76927008.
Add a new parameter attribute `@_implicitSelfCapture` that disables the
requirement to explicitly use `self.` to refer to a member of `self`
in an escaping closure.
Part of rdar://76927008.
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
The diagnosticc engine is keeping track of state which might modify parsing/typechecking behaviour. In the added test case the `fatalErrorOccurred` flag was during the first completion. The flag was still `true` for the second completion, causing parsing/typechecking to behave slightly differently. Because of this, the ExprRewriter failed when applying a constraint system solution, not properly cleaning up its `ExprStack`.
This PR tackles both issues:
1) Reset the `hadError` flags in the diagnostics engine
2) Clean up the `ExprRewriter`’s `ExprStack` when rewriting a target fails.
Either of these changes fixes the crash in the test case but I think both could manifest through different code paths in different scenarios.
Fixes rdar://76051976 [SR-14430]
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.
Introduce the notion of "unsafe" @Sendable parameters, indicated by the
hidden @_unsafeSendable parameter attribute. Closure arguments to such
parameters are treated as @Sendable within code that has already
adopted concurrency, but are otherwise enert, allowing them to be
applied to existing concurrency-related APIs to smooth the transition
path to concurrency.
Additionally, introduce the notion of an "unsafe" @MainActor closure,
for cases where we have determined that the closure will execute on
the main actor but it (also) isn't part of the type system.
Pattern-match uses of the Dispatch library's DispatchQueue to infer
both kinds of "unsafe" as appropriate, especially (e.g.) matching the pattern
DispatchQueue.main.async { ... }
to treat the closure as unsafe @Sendable and @MainActor, allowing such
existing code to better integrate with concurrency.
Implements rdar://75988966.
This wasn't a problem before since locator wasn't really used by
`ExprRewritter:coerceToType` but with Double<->CGFloat conversion
it needs the locator to be anchored at a rewritten expression instead
of the original one to form a correct implicit initializer call.
Insert an implicit call to an initializer into the AST
to model to/from CGFloat conversion and pass converted
value as an argument (left-hand side of the conversion).
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.
Lazily instantiate class template members. This means we no longer
reject some programs that clang accepts, such as the following:
```
template<class T> struct Foo { void fail(T value) { value.fail(); } };
using Bar = Foo<int>;
```
The above program will not error so long as `Bar::fail` isn't called.
(Previously, we'd fail to import `Bar`.)
