This code was organized such that one had first definitions for CleanupManager,
then CleanupStateRestorationScope, and then again CleanupManager. This is just
confusing/hard to read. This commit fixes that by creating contiguous sections
of definitions with comment flags to document said sections.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
This rename makes since since:
1. This is SILGen specific functionality.
2. In the next commit I am going to be adding a SIL SavedInsertionPoint class. I
want to make sure the two can not be confused.
This method verifies that all non-dead cleanup handles that a formal evaluation
scope would pop have not been popped yet.
The body of the function is if-defed out when asserts are disabled.
rdar://31313534
Previously, we were emitting these cleanups at the end of the lexical scope
instead of at the end of the formal evaluation scope. This change ensures that
we always emit the cleanup immediately at the end of the formal evaluation
scope.
Previously in most cases we got away with this due to the +0 self
hack. Basically we would emit a get for a self parameter and then immediately
use that self parameter as a guaranteed parameter. Then the hack would insert
the destroy value forwarding the lexical scope level cleanup at the same time.
rdar://29791263
We already have CleanupManager::dump() that dumps the entire cleanup
stack. Sometimes though when debugging you want to dump a specific cleanup. This
API provides such functionality.
This is useful to discover when a specific cleanup is being eliminated while
debugging. The implementation is compiled out when assertions are disabled.
rdar://29791263
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
DeferCleanup pushes a new temporary cleanup to catch non-local returns
from the defer block, so we have to use stable iterators while emitting
cleanups.
There's no good deterministic test case for this -- it would manifest
as memory corruption if the underlying storage of the DiverseStack
grew beyond the inline storage. Add a reduced version of the original
user-reported test case that triggers it reliably -- I had a hard time
coming up with anything simpler.
Fixes <rdar://problem/21437203>.
Swift SVN r29658
The other part of rdar://problem/21444126. This is a little trickier since SIL doesn't track uses of witness tables in a principled way. Track uses in SILGen by putting a "SILGenBuilder" wrapper in front of SILBuilder, which marks conformances from apply, existential erasure, and metatype lookup instructions as used, so we can avoid emitting shared Clang importer witnesses when they aren't needed.
Swift SVN r29544
in terms of the pattern binding/emission facilities that are currently
used for switches. They are more general (handling all patterns,
not hacked up just for optionals).
This leads to us producing better code for if/let bindings, because we
don't alloc_stack a temporary and deal with memory for non-address-only
types (e.g. the common case of an optional pointer). Instead, the code
emits a select_enum{_addr} on the value.
While this changes the generated code in the compiler, there is no exposed
behavioral change to the developer.
Swift SVN r26142
rdar://problem/19450969
Undo reverts r24381..24384 with one fix: pull cleanup blocks from the
back of the list. When breaking out of a while loop, an extra release
could over-release a reference.
Swift SVN r24553
completely destroyed when forwarded.
Also, make forwarding a cleanup a first-class operation
on cleanups, rather than setting the cleanup state directly.
Swift SVN r19332
state of a cleanup to be restored after emitting
a path that may have e.g. activated it.
This should be used very carefully, because it makes
it quite simple to foul up your cleanup logic.
To be useful for temporarily deactivating cleanups,
we need a state that prevents forwarding from killing
the cleanup.
Swift SVN r19331
The cleanup stack pointer is not reset when there are only dead cleanups in a scope, so relax this assertion to check that there are no live cleanups instead of that the cleanup handles are at the same height. Fixes <rdar://problem/16203107>.
Swift SVN r14674
I've decided to keep only the location of the scope AST node that corresponds to the cleanup. (Currently, there is no user that needs the originator expression, which caused the cleanup. So keeping things simple.)
Added the cleanup location to the Scope and JumpDest classes, which gets assigned on construction of those. The Scope's and JumpDest locations are used when we emit the cleanup instructions.
We now give better location info for 2 existing tests for definitive initialization.
(+ Rather sparse testing of all this.)
Swift SVN r7764
We mark the branch instructions leading into single epilog code with ReturnLocation/ImplicitReturnLocation. If SIL Gen simplifies the code and merges the code representing the return into the epilog block, the terminator of the epilog block (the ReturnInst) will have the return location info on it. Otherwise, the ReturnInst has the RegularLocation, which represents the enclosing FunctionExpr or Constructor/Destructor Decls.
(I've discussed dropping the optimization from SILGen, and keeping the epilog code canonical, with Adrian; but he said that there might not be any wins in doing so, so keeping it for now.)
Added AutoGeneratedLocation to represent segments of code generated by SILGen. This will be used for thunks and other auto-generated segments.
Swift SVN r7634
