In most places where we were checking "is<ErrorType>()", we now mean
"any error occurred". The few exceptions are in associated type
inference, code completion, and expression diagnostics, where we might
still work with partial errors.
The fix for missing logging for += accidentally made us log ALL functions that
return (), not just the ones that happen to touch inout parameters. That's not
really desirable, and resulted from a missing testcase.
This fixes the problem and adds a testcase.
<rdar://problem/27995558>
+= is now a class method, which means the playground transform ignores it. This
is undesirable, and we have ways to instrument methods that mutate inout
parameters the way += does. I have just made it so that if we see a method call
and we can't instrument the mutation of the base of the method call, we still
instrument the inout argument if there is one.
Also added a test case.
Yet another step on the way to SE-0111, capture the argument labels
(and their locations) directly in CallExpr, rather than depending on
them being part of the tuple argument.
Introduce several new factory methods to create CallExprs, and hide
the constructor. The primary reason for this refactor is to start
moving clients over to the factory method that takes the call
arguments separately from the argument labels. Internally, it
repackages those arguments into a TupleExpr or ParenExpr (as
appropriate) so the result ASTs are the same. However, this will make
it easier for us to tease out the arguments themselves in the
implementation of SE-0111.
Rather than duplicating the constant value, use the `sizeof` operator to have
the value propogate from the static buffer allocation. Any standards conforming
implementation of `snprintf` will null-terminate the output unless the buffer is
NULL (a zero-sized buffer is passed to the call). On Windows, where this is not
the case, the function is named `_snprintf` which ensures that we do not
accidentally end up with the incorrect behaviour.
Whenever we have a call, retrieve the argument labels from the
argument structurally and associate them with the callee. We were
previously doing this as a separate AST walk (which was unnecessary),
so fold that into constraint generation for a CallExpr. We were also
allowing weird ASTs to effectively disable this information: tighten
that up and require that CallExprs always have a ParenExpr, TupleExpr,
or (as a temporary hack) a TypeExpr whose representation is a
TupleTypeRepr as their argument prior to type checking. This gives us
a more sane AST to work with, and guarantees that we aren't losing
label information.
From the user perspective, this should be NFC, because it's mostly AST
cleanup and staging.
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
