Reimplement 'switch' parsing for our new AST representation, where cases contain patterns and 'where' guards, case blocks can have multiple cases, and 'default' is constrained to being the lone label of the last block if present. No type-checking or parsing of actual pattern productions yet.
Swift SVN r5834
This makes parsing patterns a bit more straightforward and prevents us from inadvertently accepting '_' as an identifier in a place we shouldn't.
Swift SVN r5806
parser state. Backtracking will be used a lot when we implement delayed
parsing for function bodies, and we don't want to leak lexer and parser state
details to AST classes when we store the state for the first and last token for
the function body.
Swift SVN r5759
The analyzer can't reason about the following complicated
control-dependency:
if (!isxdigit(BytesPtr[0]) || !isxdigit(BytesPtr[1]) ||
!isxdigit(BytesPtr[2]) || !isxdigit(BytesPtr[3])
continue; // Ignore invalid escapes.
StringRef(BytesPtr, 4).getAsInteger(16, CharValue);
BytesPtr += 4;
In this case, we cap the number of bytes read at 4, and we have
verified that the bytes will always form an integer. The analyzer
thinks there could be a false positive uninitialized value warning
here since 'getAsInteger()' does its own checking to see if the
parsed bytes actually compose an integer value.
Swift SVN r5566
Add a SWIFT_FALLTHROUGH macro that expands to [[clang::fallthrough]] for Clang and nothing for other compilers. No functionality change.
Swift SVN r5043
Remove '@' from the operator character set, but add the math, symbol, punctuation, arrow, and line- and box-drawing characters. Also allow operators to contain (but not start with) combining characters--this should be safe, because identifiers can't start with combining characters either, and we don't allow them anywhere else.
Swift SVN r5019
Original message:
SIL Parsing: add plumbing to know when we're parsing a .sil file
Enhance the lexer to lex "sil" as a keyword in sil mode.
Swift SVN r4988
Extend the character set for identifiers according to WG14 N1518, which recommends an extended character set for identifier start and continuation characters in C. Mangle identifiers containing non-ASCII characters by borrowing the Punycode encoding used for international domain names.
No Unicode operators just yet.
Swift SVN r4968
Per Chris's feedback and suggestions on the verbose fix-it API, convert
diagnostics over to using the builder pattern instead of Clang's streaming
pattern (<<) for fix-its and ranges. Ranges are included because
otherwise it's syntactically difficult to add a fix-it after a range.
New syntax:
diagnose(Loc, diag::warn_problem)
.highlight(E->getRange())
.fixItRemove(E->getLHS()->getRange())
.fixItInsert(E->getRHS()->getLoc(), "&")
.fixItReplace(E->getOp()->getRange(), "++");
These builder functions only exist on InFlightDiagnostic; while you can
still modify a plain Diagnostic, you have to do it with plain accessors
and a raw DiagnosticInfo::FixIt.
Swift SVN r4894
Note that we can't actually display the latter in textual format (because
the fix-it contains a newline), nor can we verify it (because the fixit
contains a newline).
Swift SVN r4813
Create a new FallthroughStmt, which transfers control from a 'case' or 'default' block to the next 'case' or 'default' block within a switch. Implement parsing and sema for FallthroughStmt, which syntactically consists of a single 'fallthrough' keyword. Sema verifies that 'fallthrough' actually appears inside a switch statement and that there is a following case or default block to pass control to.
SILGen/IRGen support forthcoming.
Swift SVN r4653
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
Implement the syntax 'if x then y else z', which evaluates to 'y' if 'x' is true or 'z' if 'x' is false. 'x' must be a valid logic value, and 'y' and 'z' must be implicitly convertible to a common type.
Swift SVN r4407
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
