Implement switch statements with simple value comparison to get the drudge work of parsing and generating switches in place. Cases are checked using a '=~' operator to compare the subject of the switch to the value in the case. Unlike a C switch, cases each have their own scope and don't fall through. 'break' and 'continue' apply to an outer loop rather to the switch itself. Multiple case values can be specified in a comma-separated list, as in 'case 1, 2, 3, 4:'. Currently no effort is made to check for duplicate cases or to rank cases by match strength; cases are just checked in source order, and the first one wins (aside from 'default', which is branched to if all cases fail).
Swift SVN r4359
If the completion prefix has a '.' behind it, guesstimate a context expression by lexing backward through an identifier(.identifier)* dotted path, then attempt to parse and typecheck that expression to decide on a base type in which to find completions.
Swift SVN r4063
It seems wrong that '=' behaves differently than the compound assignment
operators and comparison operators.
I don't feel strongly about this behavior in and of itself. We can always
revert this change later if we want to rationalize why '=' should have
grammatically different rules than say '+='.
Swift SVN r4027
The range operators (".." and someday "...") make constructs like .24...42
ambiguous. Therefore, we will enforce that programmers either place digits
on both sides of the decimal place, or use of exponent based notation.
Swift SVN r3989
If we're going to import C/C++/ObjC code, we ought to "just work" with
their escape patterns when reasonable. (No error-prone octal escapes or
trigraph support). Also, update LangRef to document what the escapes do.
This patch DOES fix a bug with lexing operators in the case of (already
warned about) embedded NUL bytes within a source file.
This patch DOES NOT change what we consider to be valid whitespace in
the language.
Swift SVN r3970
While we are not C, we should not ignore the strong Unix command-line
tool conventions that motivated the C standard to make this be a
requirement of the language and a warning in clang/gcc.
Swift SVN r3946
APFloat's parser gives us the parsing for free. Unlike C99 we require at least one digit on both sides of the hexadecimal point in order to allow '0x1.method()' expressions, similar to Dave's proposed change to float lexing. Also, we were requiring a sign after 'e' in the exponent, which is inconsistent with C, C++, and the Java regex we claim to follow, so I made the exponent sign optional.
Swift SVN r3940
If we generalize John's insight about l_(paren|square) being about
"starting" and "following" tokens, then we can detect many statement
or declaration boundaries that are lacking either white space or a
semicolon.
Ensuring some amount of whitespace between statements and declarations
is good for future proofing.
Swift SVN r3914
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
Given that we want semicolon statement separators to be optional,
literals can bump up right next to the previous statement at the moment:
'var x = y"hello".print()' is two statements right now, not one broken
expression being used to initialize to 'x'. This is unfortunate if we
ever want to support C++ style raw strings or otherwise have some back
pocket grammar tricks to implement type state or trivially unambiguous
generics.
Swift SVN r3871
Dave noted that he's trying to scrub the parser codebase of wishy-washy 'isAnyLParen' and 'isAnyLBrace' calls by consistently lexing opening bracket tokens correctly to begin with. Since currently only 'super' and 'constructor' need to be lexed like identifiers for expression syntax (and, in the future, 'this' and 'This' when those become keywords), mark them as a special kind of 'identifier keyword' in Tokens.def and roll back some of the changes I made to make parsing other decls support either token.
Swift SVN r3848
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
'.' is an operator in order to make '..' work and perhaps someday '...'
work, but we shouldn't interpret '....' as '...' followed by '.'.
Swift SVN r3705
resulting token goes back through the lexer to get the appropriate
token kind. Thanks to Chris for spotting this.
Also, document the '<' and '>' splitting behavior in LangRef.
Swift SVN r2192
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
