When users invoke code completion at an argument position, we suggest argument names,
if required however not specified, or a list of argument values. These values are annotated
with their type relation to the expected argument types, so that
Xcode can prioritize those values that apply over those that do not.
This also fixes: rdar://21727063
Swift SVN r31505
The defer body func is only ever fully applied, so SILGen can avoid allocating a closure for it if it's declared as a 'func', making it slightly more efficient at -Onone.
Swift SVN r30638
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
These variables really are local variables -- they have have a
TopLevelCodeDecl as their DeclContext rather than the SourceFile.
Treating them as global variables caused crashes in serialization.
We need an overhaul of top-level variables in script files anyway
(see rdar://problem/20992489&21628526), but this fixes the immediate
issue.
rdar://problem/21928533
Swift SVN r30519
We always expect to get a pattern, but in top-level completion we forgot
to build the fallback AnyPattern to go in the error result.
rdar://21661308
Swift SVN r30078
into the body of the for statement. Instead of ripping the body of the closureexpr
out and putting it into the C Style for, wrap up the closureExpr into a call. This
avoids breaking AST invariants because the ClosureExpr will be the DeclContext for
anything inside of it.
This fixes <rdar://problem/21679557> compiler crashes on "for{{"
... which was Practical Swift's shortest crasher.
Swift SVN r29916
I didn't add anything to the table, just made use of what was already there.
We have plenty of additional calls to getIdentifier that could probably benefit
from this kind of easy access as well.
This commit also removes FOUNDATION_MODULE_NAME and OBJC_MODULE_NAME from
Strings.h. Neither of these is likely to change in the future, and both
already have KnownIdentifiers equivalents in use.
No intended functionality change.
Swift SVN r29292
Make sure we build the CatchStmt and DoCatchStmt AST nodes when
code-completing inside the body of a catch so that we can complete the
bindings from the catch.
It's often a good idea to early-exit once we see a code completion
token, but not when we skip building an AST node that provides variable
bindings. In code completion, we don't have Scope-based lookup, and
rely on having reachable AST nodes for patterns so that we can dig the
out the bindings we need.
Also extend the pattern checking to handle "IsPattern", since we
apparently weren't handling "let x as Foo", and that affects all complex
catch patterns because of an implicit "as ErrorType" or explicit
"as NSError".
rdar://problem/21116164
Swift SVN r29070
And for "try return", "try throw", and "try let", get even more specific,
with a fix-it to suggest moving the "try" onto the expression.
rdar://problem/21043120
Swift SVN r28862
Instead, provide the location of the { in a closure expr to the argument formation as
part of the datastructure already used to manage implicit closure arguments in the parser.
Swift SVN r28818
It's not okay to filter to only ErrorType results, since we may be
trying to chain to an error type result foo.bar.getError(). And the
existing logic had no way to handle results from other modules, so we
were missing key results like 'NSError'.
Eventually we'll want to bring back something like this that handles all
modules, but as a way to bump the priority of ErrorType results rather
than to filter out everything else.
rdar://problem/20985515
Swift SVN r28716
Allow availability attributes of the form:
@available(iOS 8.0, OSX 10.10, *)
func foo() { }
This form is intended for use by third-party developers when annotating their
own declarations and uses the same syntax as #available(). This annotation
says that on iOS foo() is available on version 8.0 and newer; on OSX it is
available on 10.10; and on any other un-mentioned platform it considered
available on the minimum deployment target and greater. Just like with
For now, we support this form during parsing by synthesizing multiple implicit
long-form @available attributes. So, for example, the above annotation will
synthesize two implicit attributes:
@available(iOS, introduced=8.0)
@available(OSX, introduced=10.10)
func foo() { }
Synthesizing attributes in this way is not ideal -- it makes for a poor Fix-It
experience, among other things -- but it exposes the short-form syntax with
minimal invasiveness.
rdar://problem/20938565
Swift SVN r28647
In anticipation of adding short-form @available() annotations, move validation
of #available() platform/version lists out of Sema and into the parser. This
also enables slightly more graceful recovery from errors.
Swift SVN r28637
instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
