While applying type inferred for autoclosure to argument use locator
that records argument/param indices to make it possible for
`coerceToType` to simplify it down to underlying argument expression
if necessary.
The initializer of an 'async let' is executed as a separate child task
that will run concurrently with the main body of the function. Model
the semantics of this operation by wrapping the initializer in an
async, escaping autoclosure (representing the evaluation of the child
task), and then a call to that autoclosure (to
This is useful both for actor isolation checking, which needs to treat
the initializer as executing in concurrent code, and also (eventually)
for code generation, which needs to have that code in a closure so
that it can be passed off to the task-creation functions.
There are a number of issues with this implementation producing
extraneous diagnostics due to this closure transformation, which will
be addressed in a follow-up commit.
We used to wrap the base expression in an InOutExpr when accessing a
computed property. This was a vestigial remnant of differences in the
SILGen code paths for stored vs computed property access.
These days SILGen doesn't care and is perfectly happy to call getters
and setters with an LValueType base as well.
This allows us to remove the call to getAccessSemantics(), which for
a 'didSet', had to kick off type checking of the body.
Fixes <rdar://problem/69532933>.
It's too early to do that here, because we may be building a reference
to a ParamDecl that is not yet known to be inout, because the constraint
solver has not run yet.
Instead, always compute the access semantics in CSApply.
When building a curry thunk for unapplied references to instance
methods, the type checker would build a CallExpr rather than a
DotSyntaxCallExpr to work around various issues with source locations.
Fix the underlying issues with source locations in DotSyntaxCallExpr
so we can consistently build DotSyntaxCallExpr here, and assert that
we don't do this again:
* DotSyntaxCallExpr wasn't able to reason about having just one of its
children having source location information; fix it.
* @dynamicCallable support was passing the declaration source location
for the call expression, which was nowhere in the expression itself.
The above mistake was covering for this one.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
Generally, casting consistency demands that we be able
to extract anything from an existential that can be put
into that existential. (Which is why the casting spec
requires that casting permit arbitrary injection and
projection of optionals.)
This particular diagnostic prevented optionals from being
projected back out of existentials:
let i: Int?
let a: Any = i // Inject Int? into Any
// Error prevents projecting Int? back out of Any
a as? Int?
This also broke certain uses of Mirror (weak variables get reflected as
optionals stored in Any existentials).
Rather than trying to include each expression kind, which leaves us
open to errors of omission, exclude only the case where we don't record
locators for trailing closure directions.
The introduction of forward-scan matching for trailing closures
(SE-0286) failed to account for unresolved member expressions,
sometimes causing a crash in SILGen. Fixes rdar://problem/67781123.
Introduce a new expression type for representing the result of an unresolved member chain. Use this expression type instead of an implicit ParenExpr for giving unresolved member chain result types representation in the AST during type checking.
In order to give unresolved member chain result types visibility in the AST, we inject an implicit ParenExpr in CSGen that lives only for the duration of type checking, and gets removed during solution application.
Remove the tracking of unresolved base types from the constraint system, and place it entirely within the generation phase. We have other ways of getting at the base types after generation.