Fixes SR-2757.
Variables in capture lists are treated as 'let' constants, which can
result in misleading, incorrect diagnostics. Mark them as such in order
to produce better diagnostics, by adding an extra parameter to the
VarDecl initializer.
Alternatively, these variables could be marked as implicit, but that
results in other diagnostic problems: capture list variables that are
never used produce warnings, but these warnings aren't normally emitted for
implicit variables. Other assertions in the compiler also misfire when
these variables are treated as implicit.
Another alternative would be to walk up the AST and determine whether
the `VarDecl`, but there doesn't appear to be a way to do so.
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.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
After recent changes, this asserts on all decls that are not VarDecls,
so we can just enforce that statically now. Interestingly, this turns
up some dead code which would have asserted immediately if called.
Also, replace AnyFunctionRef::getType() with
AnyFunctionRef::getInterfaceType(), since the old
AnyFunctionRef::getType() would just assert when called on
a Decl.
Previously, getInterfaceType() would return getType() if no
interface type was set. Instead, always set an interface type
explicitly.
Eventually we want to remove getType() altogether, and this
brings us one step closer to this goal.
Note that ParamDecls are excempt from this treatment, because
they don't have a proper interface type yet. Cleaning this up
requires more effort.
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
