Similarly to how we've always handled parameter types, we
now recursively expand tuples in result types and separately
determine a result convention for each result.
The most important code-generation change here is that
indirect results are now returned separately from each
other and from any direct results. It is generally far
better, when receiving an indirect result, to receive it
as an independent result; the caller is much more likely
to be able to directly receive the result in the address
they want to initialize, rather than having to receive it
in temporary memory and then copy parts of it into the
target.
The most important conceptual change here that clients and
producers of SIL must be aware of is the new distinction
between a SILFunctionType's *parameters* and its *argument
list*. The former is just the formal parameters, derived
purely from the parameter types of the original function;
indirect results are no longer in this list. The latter
includes the indirect result arguments; as always, all
the indirect results strictly precede the parameters.
Apply instructions and entry block arguments follow the
argument list, not the parameter list.
A relatively minor change is that there can now be multiple
direct results, each with its own result convention.
This is a minor change because I've chosen to leave
return instructions as taking a single operand and
apply instructions as producing a single result; when
the type describes multiple results, they are implicitly
bound up in a tuple. It might make sense to split these
up and allow e.g. return instructions to take a list
of operands; however, it's not clear what to do on the
caller side, and this would be a major change that can
be separated out from this already over-large patch.
Unsurprisingly, the most invasive changes here are in
SILGen; this requires substantial reworking of both call
emission and reabstraction. It also proved important
to switch several SILGen operations over to work with
RValue instead of ManagedValue, since otherwise they
would be forced to spuriously "implode" buffers.
We need to increment the counter for repeat-while bodies immediately
after the loop body is entered. This allows us to handle "break" and
"return" statements in the repeat-while body correctly.
This also fixes an off-by-one error where we only updated the
repeat-while body counter when the loop condition evaluates to true.
This change is needed for the next update to ToT LLVM. It can be put
into place now without breaking anything so I am committing it now.
The churn upstream on ilist_node is neccessary to remove undefined
behavior. Rather than updating the different ilist_node patches for the
hacky change required to not use iterators, just use iterators and keep
everything as ilist_nodes. Upstream they want to eventually do this, so
it makes sense for us to just do it now.
Please do not introduce new invocations of
ilist_node::get{Next,Prev}Node() into the tree.
We were emitting the counter for falling out of a do block at the end
of the entire construct's scope, but this can cause us to miss the
increment if the insertion point isn't valid there. Move the increment
to immediately after we emit the body.
rdar://problem/22346924
Swift SVN r31356
This gets the cleanups right, which is important for the 'locals' that
come from top-level guard statements as well as top-level defer statements.
The former could lead to accessing destroyed memory.
rdar://problem/22064894
Swift SVN r30811
The defer body func is only ever fully applied, so SILGen can avoid allocating a closure for it if it's declared as a 'func', making it slightly more efficient at -Onone.
Swift SVN r30638
We were creating a coverage mapping for GuardStmt, but we were never
incrementing its counter, so the results were quite strange. This
moves the counter to the body of the guard (instead of the
non-existent "then" clause) and increments the counter in the obvious
place.
rdar://problem/21291670
Swift SVN r29965
a do or do-catch block to point to end of the do body rather than the
location of the "do" keyword.
<rdar://problem/21194177> line table entries for "do" happen after the body of the do is executed
Swift SVN r29239
When emitting try_apply, don't start a new scope between adding
a cleanup and forwarding the value. This would leave behind a
dead cleanup, which would fire an assertion in emitSharedCaseBlocks().
Fixes <rdar://problem/20923654>.
Swift SVN r28572
in memory when it is address-only. This leads to better -O0 performance and
easier to read silgen output. This is ongoing progress towards rdar://20642198.
Swift SVN r28318
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
