Add a counter in each catch block and one for the fallthrough out of
the entire do-catch block, and implement the logic to handle these and
throw statements in the coverage mapping.
Swift SVN r27950
Now we bind the defer body into a ClosureExpr and emit it at the point of
the defer. At any exit points out of the controlled region, we emit a call
to the closure.
This should cover any problems where expressions cannot be emitted multiple times.
However, this is dramatically more complex than the obvious implementation, so I
hope this patch can be reverted.
Swift SVN r27767
missing piece now is Sema support for detecting invalid exits
out of defer bodies. That said, SILGen will also detect it,
and produce an error if sema misses something, e.g.:
t.swift:11:23: error: defer statement is not allowed to be exited
while false { defer { break } }
^
t.swift:12:9: error: defer statement is not allowed to be exited
defer { return }
^
we should still diagnose these in Sema for better QoI of course.
This wraps up: <rdar://problem/17302850> Add a defer keyword to swift
Swift SVN r27760
Change all uses of "do { ... } while <cond>" to use "repeat" instead.
Rename DoWhileStmt to RepeatWhileStmt. Add diagnostic suggesting change
of 'do' to 'repeat' if a condition is found afterwards.
<rdar://problem/20336424> rename do/while loops to repeat/while & introduce "repeat <count> {}" loops
Swift SVN r27650
emission instead of hand coded magic. Eliminating special cases allows simplifying
other parts of the compiler, and this probably helps the error handling initiative
as well.
This uses the (horrible) new null_class instruction to properly model rebinding of
self. The code that SILGen was producing before was wildly incorrect and we only
got lucky that it seemed to work in most cases before.
NFC except that SILGen tests see the new null_class instructions, and we get better
location info for 'return nil' for obscure reasons that don't really matter.
Swift SVN r27530
already set up, allowing clients to generate code before the top-level
cleanup stack is emitted.
Use this to switch value constructors onto emitEpilog() and, more importantly,
to start managing the self box as a normal local variable tracked with cleanups
instead of being tracked with ad-hoc code spread through SILGen.
Among other things, once classes are switched over to the same model, we can
remove SGF.FailSelfDecl and the code to support it. NFC.
Swift SVN r27472
- Use virtual dispatch to localize some predicates instead
of having special cases for LetValue inits in global places.
- Improve 'const'ness of methods.
- Introduce a common "KnownAddressInitialization" class to centralize
the notion of an initialization corresponding to a specific physical
address that is known up front. Consolidate dupes of this concept into
uses of it.
NFC.
Swift SVN r27462
This change permits SILGen to make smarter decisions about
block placement by keeping related blocks together instead
of always inserting to the end to the function. The
flipside is that SILGen needs to be somewhat careful to
create blocks in the right order. Counter-intuitively,
that order is the reverse of the order in which the blocks
should be laid out, since blocks created later will be
inserted before blocks created earlier. Note, however,
that this produces the right results for recursive
emission.
To that end, adjust a couple of places in SILGen to
create blocks in properly nested order.
All of the block-order differences in the tests seem
to be desirable; several of them even had confused
comments wondering how on earth a block got injected
where it did.
Also, fix the implementation of SILBuilder::moveBlockTo,
and fix a latent bug in epilogue emission where epilogBB
was erased from its parent (deleting it) and then
queried multiple times (!).
Swift SVN r26428
This patch also introduces some SILGen infrastructure for
dividing the function into "ordinary" and "postmatter"
sections, with error-handling-like stuff going into the
final section. Currently, this is largely undermined by
SILBuilder, but I'm going to fix that in a follow-up.
Swift SVN r26422
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
For now, we assume that 'while' after the braces starts
a do/while rather than being an independent statement.
We should disambiguate this, or better, remove do/while.
Tests later.
Swift SVN r26079
This doesn't allow 'continue' out of an if statement for the same reason we don't
allow it on switch: we'd prefer people to write loops more explicitly.
Swift SVN r25565
This adds the -profile-generate flag, which enables LLVM's
instrumentation based profiling. It implements the instrumentation
for basic control flow, such as if statements, loops, and closures.
Swift SVN r25155
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
emitted just the optional buffers, and tested them when evaluated the condition, then
consumed them all (producing the contained value) when the entire condition is true.
This doesn't work with where conditions, because the where condition can use the bound
variables.
The new approach emits the variable bindings as the conditions is emitted, allowing the
bindings to be in scope for where clauses. In addition to this redesign, the implementation
is also somewhat simpler by being a recursive implementation which is (to me at least)
easier to reason about.
multi-pattern where bindings with where clauses should now be fully operational.
Swift SVN r24360
known implementation work required for:
<rdar://problem/19382942> Improve 'if let' to avoid optional pyramid of doom
I want to write some more tests and improve error recovery QoI in the parser,
but I believe it fully works now. Please kick the tires and let me know if
you observe any problems (other than 19432424 which was pre-existing).
Swift SVN r24348
if-let statements (also while and var, of course) that include multiple bindings
and where clauses.
SILGen support still remains, it currently just asserts on the new constructs.
Swift SVN r24239
"isConstant" distinction. This was an irritating bit of redundant state
that was making the code more complicated. Clients of VarLoc really only
care about "has address" and "has box", not whether the VarLoc came from
a let or var (and if they did, they can ask the VarDecl directly). NFC,
just more "yak shaving" as Doug likes to say.
Swift SVN r23869
When we've already established that the optional has a value, using unchecked_take_enum_data_addr to directly extract the enum payload is sufficient and avoids a redundant call and check at -Onone. Keep using the _getOptionalValue stdlib function for checked optional wrapping operations such as "x!", so that the stdlib can remain in control of trap handling policy.
The test/SIL/Serialization failures on the bot seem to be happening sporadically independent of this patch, and I can't reproduce failures in any configuration I've tried.
Swift SVN r22537
When we've already established that the optional has a value, using unchecked_take_enum_data_addr to directly extract the enum payload is sufficient and avoids a redundant call and check at -Onone. Keep using the _getOptionalValue stdlib function for checked optional wrapping operations such as "x!", so that the stdlib can remain in control of trap handling policy.
Swift SVN r22533
A couple reasons for this:
- How 'self' gets cleaned up is dependent on where the failure occurs. If we propagate failure from a class initializer, the failed 'super.init' or 'self.init' has already cleaned up the object, so we only need to deallocate the box. In cases where we fail explicit, we release 'self', which works out because we're only supporting failure with a fully-initialized object for now.
- This lets us set the location info for the cleanup to the AST node that instigated failure, giving better QoI for DI failures (such as failing with a partially-initialized object).
Swift SVN r21505
