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
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
