This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
This commit completes an unresolved member with all visible enum elements.
We need future work to reduce the list to those that are guaranteed to be
resolved under the current context.
Swift SVN r31063
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
(Undoing revert r30961 of r30957, which just required lockstep commit to
SourceKit -- cwillmore)
Swift SVN r30962
This reverts r30957 because it broke the following tests on Jenkins:
SourceKit :: CodeComplete/complete_open.swift
SourceKit :: CodeComplete/complete_test.swift
<rdar://problem/22120345> swift-incremental-RA #8289 failed to build
Swift SVN r30961
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
Swift SVN r30957
Compute the hash of all interface tokens when parsing; write the
interface hash to the swiftdeps file, or if the -dump-interface-hash
option is passed to the frontend. This hash will be used in incremental
mode to determine whether a file's interface has changed, and therefore
whether dependent files need to be rebuilt in response to the change.
Committed on ChrisW's behalf while he gets his setup unborked.
rdar://problem/15352929
Swift SVN r30477
When a line begins with '.', it's almost always due to a method chain, not an attempt to start an expression with a contextual member lookup. This is a more principled grammar rule than the long tail of hacks we've been putting up to try to accommodate "builder pattern" usages. Fixes rdar://problem/20238557.
Swift SVN r29606
Fixes a problem where curried parameter lists of operator function
definitions were being treated inconsistently, complaining about
removing an argument label but pretending that the parameter didn't
have an argument label to start with. Fixes rdar://problem/21275319.
Swift SVN r29346
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
Factor out the special case condition for deciding whether a period_prefix should be treated like a MemberRef postfix production instead of a new UnresolvedMemberExpr, and share it with the generic type disambiguation code, so that 'Foo<T>\n.bar()' parses consistently with 'Foo\n.bar()'. Extend the condition to consider a '.foo' reference on a line by itself in postfix position as a postfix continuation as well, allowing properties to be chained in builder fashion too. Addresses rdar://problem/20238557, but we may want to still make a more general change to the grammar here.
Swift SVN r28707
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
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
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Change the syntax of availability queries from #available(iOS >= 8.0, OSX >= 10.10, *) to
This change reflects the fact that now that we spell the query '#available()' rather than
'#os()', the specification is about availability of the APIs introduced in a particular OS
release rather than an explicit range of OS versions on which the developer expects the
code to run.
There is a Fix-It to remove '>=' to ease adopting the new syntax.
Swift SVN r28025
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
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
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
Add syntax "[#Color(...)#]" for object literals, to be used by
Playgrounds for inline color wells etc. The arguments are forwarded to
the relevant constructor (although we will probably change this soon,
since (colorLiteralRed:... blue:... green:... alpha) is kind of
verbose). Add _ColorLiteralConvertible and _ImageLiteralConvertible
protocols, and link them to the new expressions in the type checker.
CSApply replaces the object literal expressions with a call to the
appropriate protocol witness.
Swift SVN r27479
The API review list found it confusing that if #os() and #if os() looked so similar, so
change the availability checking query to be spelled #available:
if #available(iOS >= 9.0, *) {
...
}
Swift SVN r26995
On platforms that are not explicitly mentioned in the #os() guard, this new '*'
availability check generates a version comparison against the minimum deployment target.
This construct, based on feedback from API review, is designed to ease porting
to new platforms. Because new platforms typically branch from
existing platforms, the wildcard allows an API availability check to do the "right"
thing (executing the guarded branch accessing newer APIs) on the new platform without
requiring a modification to every availability guard in the program.
So, if the programmer writes:
if #os(OSX >= 10.10, *) {
. . .
}
and then ports the code to iOS, the body will execute.
We still do compile-time availability checking with '*', so the compiler will
emit errors for references to potentially unavailable symbols in the body when compiled
for iOS.
We require a '*' clause on all #os() guards to force developers to
"future proof" their availability checks against the introduction of new a platform.
Swift SVN r26988
