Specifically, we now report type-checking errors in
added instrumentation to llvm::errs() and try to
restore the ASTs to their former state.
As Jordan points out, this requires a better and
more full solution, involving some form of AST
cloning or doing the playground transform at the
SIL level. I have left in a TODO to that effect.
<rdar://problem/20444876>
Swift SVN r29798
This only appears in the print logging for now.
I've got to figure out a way of transforming
print() calls without building temporary variables
left and right.
<rdar://problem/21412489>
Swift SVN r29683
errors. These errors are now printed to errs() and
the data they produce is not used, avoiding crashes
later in SILGen when we encounter ErrorTypes.
<rdar://problem/20444876>
<rdar://problem/21321078>
...
Swift SVN r29674
debugPrint() APIs correctly. PlaygroundLogger implements
APIs that always take a boolean as their second argument.
If print()/debugPrint() are called with just one argument,
we add "true" as the second argument and replace the call
with a call to the appropriate PlaygroundLogger API.
Also modified the testcase to verify that this is happening
correctly, including when the boolean argument comes from a
more complicated expression.
<rdar://problem/21084145> [Swift integration] Playground AST rewrites not updated for latest Swift standard library changes
Swift SVN r28946
We were asserting (and doing the wrong thing) when trying to code
complete
nil #^HERE^#
The issue is that we tried to apply a solution to the expression that
contained free type variables (converted to generic parameters). This
trips us up when we expect the new type to conform to protocols. In code
completion we generally only need the type of the expression, so this
commit switches to getting that more explicitly. That said, this did
cause us to drop non-API parameter names in call patterns after an
opening '(' in some cases (covered by rdar://20962472).
Thanks to Doug for suggesting this solution!
rdar://problem/20891867
Swift SVN r28584
all the strange and wonderful new ways of printing
things. Also addeed a testcase.
Note: this does not yet pass information about
which version (print vs. debugPrint) is called and
whether a newline is desired or not; that will be
in a future commit once the PlaygroundLogger
support for that is in a build.
<rdar://problem/20859024>
Swift SVN r28518
Verify that this bit is set during type-checking on
every ApplyExpr, and fix the remaining locations where
we weren't doing coverage testing on expressions; most
of these were harmless, but it's better to be safe.
Swift SVN r28509
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
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
each instrumentation point. This ID should only be a way to
identify a point for the purposes of the current run, so it is
somewhat random.
<rdar://problem/18788357> Instrumenter should start sending unique ID information for each logged entry to playgroundlogger
Swift SVN r23286
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
Instrumenting "self" might make the constructor
use "self" before calling its parent's constructor,
causing a SIL error.
Added a matching testcase.
<rdar://problem/17765562>
Swift SVN r20660
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
