When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
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
there are two possible situations here:
1) This code never runs on invalid code, in which case this argument does nothing.
2) This code does run on invalid code, and the type checker would crash as
TypeCheckExpr attempted to apply the solution.
This causes no regressions on the playground logger testsuite, but I'm not really confident
in this so I'll chat with Sean.
Swift SVN r30182
and getTypeOfExpressionWithoutApplying and change typeCheckExpression
to take it as a single-entry OptionSet, in prep for getting other
options. NFC.
Swift SVN r30121
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
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
