Keep track of all of the type parameters and archetypes that are captured
by a local function or closure. Use that information to diagnose cases
where a non-Sendable metatype crosses an isolation boundary.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Specifically, CaptureInfo previously as a pattern in CaptureInfo.cpp would
attempt to ascertain if a CapturedValue was a local capture by checking the
CapturedValue's decl. Unfortunately, when we have captured dynamic self
metadata, we do not even have a getDecl() and should return false.
I fixed this by adding a new API to CaptureValue that checks if it has a decl
before checking if the decl is a local capture. This avoids this problem.
This commit adds a new ValueDecl::isLocalCapture() predicate and
uses it in the right places. The predicate is true if the
declaration is in local context, *or* if its at the top level of
the main source file and follows a 'guard' statement.
Fixes <rdar://problem/23051362> / <https://bugs.swift.org/browse/SR-3528>.
The autoclosures generated for the keypath-as-function feature were not added to the list of closures that needed captures computed. In top-level code, this caused a crash. Fixes rdar://problem/56055600.
If there are any actual captures, a CaptureInfoStorage will be
allocated in the ASTContext, matching the previous behavior of
allocating the array of captures there.
No functionality change. I /tried/ to change the functionality to
assert everywhere capture info was used but hadn't explicitly been
computed, but it turns out we do that /all over the place/ for any
declaration that's been synthesized, imported, or deserialized. I
left in some groundwork for someone to make this more explicit (or
requestify it) in the future.
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
This also adds some tests for the existing generic parameter
capture logic, which was only tested as part of SILGen tests
until now.
Also, move capture analysis into a new TypeCheckCaptures.cpp file.
We already have the restriction that captures can't be computed until
everything is type-checked, but previously we tried to compute captures
/immediately/ after a closure was type-checked. Unfortunately, we either
type-checked too early (before @noescape was propagated onto multi-statement
closures) or too late (trying to compute autoclosure captures at the point
the autoclosure was introduced).
Now, all closure captures are computed after type-checking, and local
function captures as well. They also more consistently reuse the capture
list of nested closures/functions. Because captures can be computed on
demand, there is now a flag on CaptureInfo for whether we've computed
captures yet. Note that some functions will never have captures computed,
namely those that are not in a local context.
rdar://problem/19956242
Swift SVN r25776
Turns out llvm::DataLayoutPass is used in other places, so the bots are still unhappy.
Re-applying the original change so we can fix the problem holistically.
Swift SVN r25761
This is breaking the testing bot because DataLayoutPass was just removed from LLVM trunk.
Chris is the best one to fix this change, but we need to get the bots green.
Swift SVN r25760
- Have Sema, not SILGen decide if a vardecl can be captured by address
instead of by-box. This is a non-local property that is best computed
during capture set formation. Sema captures this as a bit on the new
CapturedValue entry.
- Rework some diagnostic emission to centralize a class of noescape
diagnostics in capture set calculation. Previously, funcdecl closures
produced their diagnostics there, but ClosureExprs produced them in
MiscDiagnostics (NFC for this part).
This fixes <rdar://problem/19981118> Swift 1.2 beta 2: Closures nested in @noescape closures copy, rather than reference, captured vars.
Swift SVN r25759
the DeclRefExpr's access semantics is "direct to storage" instead of basing it
on the weird special case we were using before.
- Change AST dumper to print the "direct" flag.
NFC.
Swift SVN r25749
when computing the list. This simplifies getLocalCaptures to *just* filter out
global captures, and paves the way for other enhancements. NFC.
Swift SVN r25739
Most of the complexity here is teaching SILGen how to handle closed-over direct
accesses to observing properties, since all of the getter/setter/willSet/didSet
members of the property are actually full closures when in a function body.
We generate correct but really terrible code here, since the setter captures the
willset/didset members themselves. I'm not worrying about the performance of
this construct though, functionality is what matters.
Swift SVN r13778
