Based off the PlaygroundTransform, this new ASTWalker leaves calls to __builtin_pc_before and __builtin_pc_after before and after a user would expect a program counter to enter a range of source code.
We no longer try to change the print() statement. I updated the tests, too.
<rdar://problem/22079705> ER: PlaygroundTransform support for print() API
Swift SVN r30891
We put the argument to be printed (so not the stream or the appendNewline:) into
a temporary variable to avoid type-checking nastiness. I also made the test
case considerably more comprehensive.
<rdar://problem/21905513> [Swift submission] playgrounds need to handle print with weird arguments
Swift SVN r30457
Leave the qualification off of enum cases and type names when 'print'-ing them, but keep them on 'debugPrint'. (At least, at the outermost level; since ad-hoc printing of structs and tuples uses debugPrint, we'll still get qualification at depth, which kind of sucks but needs more invasive state management in print to make possible.) Implements rdar://problem/21788604.
Swift SVN r30166
We had a bit of back-and-forth over how to handle type-check errors in added
expressions. Obviously all added expressions *should* type-check -- but we
don't want the compiler (and, by extension, the XPC playground service) crashing
when they don't. So the ErrorTypes from failed type-checks must not leak into
existing code.
In this solution, we use a convenience class (Added) that wraps an expression.
It marks expressions we've constructed -- and we're only allowed to type-check
Added<Expr*>s. (This isn't fully enforced -- you could still have Added<Expr*>s
that refer to existing Expr*s) but adding this and plumbing it through caught
most of the problems.
I also added checks to various places that weren't checking whether type
checking succeeded. In one case where we were emitting a source location for
one element in a TupleExpr but not emitting source locations for the others
(which caused dumping to assert) I eliminated that source location.
Finally I added several test cases. These cases used to crash; one of them
works perfectly now and I've XFAILed the other two.
<rdar://problem/20444876>
Swift SVN r29842