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.
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.
The reason why I am doing this is before this commit despite the fact that
CapturedValue was only used by TypeLowering, this constructor was exposed to the
entire rest of the compiler. This made it so that other code (like the
AbstractClosureExpr::getIsolationCrossing() that I added in the previous series
of commits) would have to handle that API even though there was nothing to
handle just in case someone added something in the future.
Rather than create such a burden on the rest of the compiler, in this commit, we
instead hide said constructor and make it only accessible from
TypeLowering. This creates a barrier from new uses appearing in AST and make it
reasonable for code in the AST that will never see things from TypeLowering
(like the ACE API I mentioned above) just assert on that case without needing to
worry about additional uses cropping in easily by mistake.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
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.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
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.
TypeAlignments.h predates this whole mess; it was used for types with
stronger alignment in PointerLikeTypeTraits than the old default of
"2 by fiat and assumption". All remaining forward-declared types are
AST types, so fold them into TypeAlignments.h.
(The one exception is SILTypeList.h, but that's already gone on master.)
To avoid future ODR issues, explicitly include TypeAlignments.h into
every header that defines a type it forward-declares.
I wish we could use partial specialization to provide PointerLikeTypeTraits
for all derived classes of Decl, TypeBase, etc, but that's not something
you can do in C++ if you don't control the traits class.
The CaptureInfo computed by Sema now records if the body of the
function uses any generic parameters from the outer context.
SIL type lowering only adds a generic signature if this is the
case, instead of unconditionally.
This might yield a marginal performance improvement in some cases,
but more interestingly will allow @convention(c) conversions from
generic context.
Swift SVN r32161
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
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
