used on init decls, with the same semantics as "-> Self". Switch the ast
printer, and fixits to use it.
As driveby's, simplify verification of contextual keywords in declparsing,
and rename parseConstructor/Destructor to parseInit/Deinit.
Swift SVN r17356
This is part of <rdar://problem/16782966> make weak and unowned be context sensitive keywords
The part still missing is where we ban the attribute with a fixit to use the
non-attribute syntax.
Swift SVN r17235
This restructures IfConfigDecl/Stmt to be a list of clauses controlled
by a condition. This makes it straight-forward to drop in #elseif support.
While I'm in here, this patch moves checking for extraneous stuff at the
end of the #if line from the lexer to the parser. This means that you can
now put a comment on the same line as a #if/#else/#elseif/#endif.
Swift SVN r16912
Parse the new function syntax, which allows both the argument (API)
and parameter (internal) name to be specified prior to the colon
within each parameter. Don't re-use the existing pattern-parsing
logic. Rather, implement a new (far simpler) parser for this purpose,
then map from its simple data structures to ArgParams and BodyParams
as we're used to.
There are a number of caveats here:
- We no longer have the ability to use patterns for parameters in
function declarations. The only place this really has an impact is
that it makes the ~> hack in the standard library even uglier.
- This exposed some issues with code completion with generic
parameters that need to be investigated.
- There's still some work to be done to improve recovery when things
parse poorly within a parameter list; there are some XFAILs to deal
with that.
I'll address the last two issues with follow-up commits.
Swift SVN r15967
Track whether an identifier token is an escaped identifier token so that 'isContextualKeyword' can say "no" when an identifier is escaped.
Swift SVN r14712
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
We can attach comments to declarations. Right now we only support comments
that precede the declarations (trailing comments will be supported later).
The implementation approach is different from one we have in Clang. In Swift
the Lexer attaches the comments to the next token, and parser checks if
comments are present on the first token of the declaration. This is much
cleaner, and faster than Clang's approach (where we perform a binary search on
source locations and do ad-hoc fixups afterwards).
The comment <-> decl correspondence is modeled as "virtual" attributes that can
not be spelled in the source. These attributes are not serialized at the
moment -- this will be implemented later.
Swift SVN r14031
Require that either T be default constructible or that the user provide a closure that maps indices to initial values. We don't actually call the closure yet to initialize the array; that's blocked on function abstraction difference <rdar://problem/13251236>.
Swift SVN r8801
* Added a mode in swift-ide-test to test code completion. Unlike c-index-test,
the code completion token in tests is a real token -- we don't need to
count lines and columns anymore.
* Added support in lexer to produce a code completion token.
* Added a parser interface to code completion. It is passed down from the
libFrontend to the parser, but its functions are not called yet.
* Added a sketch of the interface of code completion consumer and code
completion results.
Note: all this is not doing anything useful yet.
Swift SVN r6128
Now that we enforce semicolon or newline separation between statements, we can relax the whitespace requirements on '(' and '[' tokens. A "following" token is now just a token that isn't at the start of a line, and any token can be a "starting" token. This allows for:
a(b)
a (b)
a[b]
a [b]
to parse as applications and subscripts, and:
a
(b)
a
[b]
to parse as an expr followed by a tuple or an expr followed by a container literal.
Swift SVN r4573
Provide distinct syntax 'a as T' for coercions and 'a as! T' for unchecked downcasts, and add type-checker logic specialized to coercions and downcasts for these expressions. Change the AST representation of ExplicitCastExpr to keep the destination type as a TypeLoc rather than a subexpression, and change the names of the nodes to UncheckedDowncast and UncheckedSuperToArchetype to make their unchecked-ness explicit and disambiguate them from future checked casts.
In order to keep the changes staged, this doesn't yet affect the T(x) constructor syntax, which will for the time being still perform any construction, coercion, or cast.
Swift SVN r4498
In Swift the "in" keyword is really a form of punctuation, and highly
context specific punctuation at that. It never begins a statement, nor
does the grammar require it be statement keyword. The grammar also
doesn't use it outside of for-each loops, and its use within a for-each
loop is highly unambiguous.
Thanks to Chris for the performance related feedback. This improves the
performance of getter/setter parsing as well.
Swift SVN r3880
Opening brackets after a keyword have to lex as l_paren_call or l_square_subscript in order for expressions like 'super.constructor()' or 'super[i]' to parse. While we're here, let's move the keyword and punctuator list to a metaprogrammable Tokens.def header too. Update decl and stmt parsers to use 'isAnyLParen' so that, e.g., 'constructor(' and 'constructor (' both work as before.
Swift SVN r3846
The lexer now models tuples, patterns, subscripting, function calls, and
field access robustly. The output tokens are now better named as well:
l_paren and l_paren_call, and l_square and l_square_subscript. It
should be much more clear now which one to use. Also, the use of
l_paren or l_square will not arbitrarily flip flop if the token before
it is a keyword or if the token before it was the trailing ']' of an
attribute list. Similarly, tuples will always cause the lexer to produce
l_paren, regardless if the user typed '((x,y))' or '( (x,y))'.
When we someday add array literals, the right token is now naturally
falling out of the lexer.
Swift SVN r3840
and use this information as cues in the language. Right now,
we do not accept things like "-- *i" because the prefix
operator is not correctly right-bound; instead you have to
write "--(*i)". I'm okay with that; I did add a specialized
diagnostic recognizing operator-binary in a place where we're
expecting a potential operator-prefix.
Swift SVN r2161
Per discussion, this should probably be "no newline since the last
token", but that decision should be made simultaneously for ( and [.
Swift SVN r1461
