and println() calls, forwarding them appropriately
to versions in the PlaygroundLogger.
Also fixed a crash when dumping the instrumentation
call for debug purposes, by giving the arguments to
the call proper source locations.
<rdar://problem/16762680>
Swift SVN r20200
This transform routine needs some serious work, because it's quadratic
in the number of elements (due to vector insertions everywhere) and
not resilient to type-checking failures. However, this
removing-null-elements hack is progress.
Swift SVN r18557
transforming top-level code. This involves these
changes:
- The playground transform now looks for functions
and top level code throughout the source file
rather than identifying a single function whose
body needs to be transformed.
- The playground transform now does not look for
VarDecls to transform; rather it looks for
PatternBindingDecls with initializers. This
is because the VarDecls are typically at top
level, where logging code can't be added, but
the PatternBindingDecls are already in
TopLevelCodeDecls.
<rdar://problem/16977837>
Swift SVN r18522
to initialize variables using lvalues. Instead
it now uses a LoadExpr to convert the lvalue to
an rvalue before using it as an initializer.
<rdar://problem/16812526>
Swift SVN r17553
As part of this, use tail allocation to reduce the memory footprint of
TupleExprs. Use factory methods to make it easier to construct.
I'll be using this information in a follow-on patch. SourceKit
probably wants it as well.
Swift SVN r17129
problems related to scopes:
- First, the return value was being printed
after the relevant scope exits. I switched
the order.
- Second, two "global" scopes were being
emitted -- one for the wrapper function,
and one for the wrapper "if" statement. We
only need one, so I added necessary gating.
<rdar://problem/16765632>
Swift SVN r17122
to properties of objects as mutations of the underlying
object. This means that we report the new state of the
object rather than reporting the value of what was
assigned to the property.
<rdar://problem/16688167>
Swift SVN r17065
of the final token in each source range rather than
its beginning. This means we report much better
character ranges.
<rdar://problem/16603092>
Swift SVN r17063
of statements like "x += y". This involved two changes:
- Where we previously only treated CallExprs as function
calls, now we instead look at ApplyExprs. This covers
cases like this += call, which is actually a BinaryExpr.
- For all such Exprs, if there is exactly one inout
argument and the Expr returns void, log that argument.
<rdar://problem/16609821>
Swift SVN r17046
name of the affected variable when appropriate
(i.e., for declarations, mutations, and
assignments).
Also removed an unused function.
<rdar://problem/16583133>
Swift SVN r17006
require that the modules it uses are present.
LLDB now explicitly forward-declares the builtins
that transformed code requires, so we can just
use them.
This makes the playground transform less error
prone, and means that if the functions really are
missing we'll get a nice and obvious link error
rather than a hard-to-diagnose error where the
playground transform quietly refuses to do
anything.
<rdar://problem/16599338>
Swift SVN r16563
to support brace entry/exit. We now maintain a
stack of brace statements we know we're inside.
The elements of this stack are colored:
- If we encounter a loop, while we are walking
that loop we color its container to indicate
that "break" and "continue" exit all braces
up until the container of the loop.
- If we encounter a function, while we are
walking that function we color its container
to indicate that "return" exits all braces
up until the container of the function.
Since at this point every BraceStmt is modified,
we don't need the "Modified" flag and I excised
it.
Swift SVN r16230
entries and exits.
- Added support to buildLoggerCall for different
logger functions;
- Added support to buildLoggerCall to handle
source locations that fall outside the
user-entered expression text; and
- Added the necessary logging functions to the
functions we check for before adding our
instrumentation.
This involved some minor refactoring. I still have
to add a stack of scopes that I can pop out of when
I see a break, continue, or return.
Swift SVN r16197
caused direct logging of expression to fail type
check sometimes. We introduce an intermediate
variable, so instead of (pseudocode)
3 -> log(3)
we have
3 -> var tmp = 3; log(tmp)
Swift SVN r16189
- Fixed a bug where it did not instrument a "for-in" loop.
- Made sure nested function declarations' bodies are
instrumented.
- Added instrumentation for return statements.
<rdar://problem/16516131>
Swift SVN r15960
- Don't be so sensitive about how many of the
required functions there are; and
- Don't include the "header" parameter to
playground_log any more; it's not needed.
Swift SVN r15755
loop constructs and mutations of variables.
We also try to ignore expressions that return
empty tuples, because this causes type-checking
failures.
Swift SVN r15568
- use the most recent prototype for the logger
function (playground_log), and
- send the output of the logger function to
DVTSendPlaygroundLogDataToHost.
Swift SVN r14892
"Playground Transform." This is an
instrumentation pass that adds calls to a
function called playground_log at locations of
interest. Roughly speaking, these locations are
- Initialization of variables
- Modification of variables
- Expressions returning values
- Application of mutating methods on objects
The playground transform currently only finds
modifications of variables, but the intent is to
make all of these cases work.
It is enabled by a frontend option, and can
also be invoked by calling
swift::performPlaygroundTransform(SF)
which is the way LLDB, its main client, will
use it.
The frontend option is intended for testing,
and indeed I will add tests for this
transformation in the coming week as I bring
more functionality online.
Swift SVN r14801
