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
This nests top level PatternBindingDecls (in "main modules") under TopLevelCodeDecls,
instead of having them live in a translation unit. They contain code that is executed,
so they should be in a TLCD.
Swift SVN r4668
Extend the existing "isTerminatorForBraceItemListKind" logic to
handle the special case for top level code, instead of having
weird logic dumped in the middle of parseBraceItemList with no comments.
This logic is still seriously dubious, but at least it is out of the way
instead of dump into already really complex logic.
Swift SVN r4665
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
own TLCD. This is important to preserve the ordering of stmt and expr w.r.t.
PatternBindingDecls that initialize the decls.
We keep the BraceStmt wrapping it to make it more similar to other decls
though.
Swift SVN r4626
Unfortunately, this regresses the repl when expressions like (1,2) are entered. This is because the repl is violating some invariants (forming dags out of ASTs, making ASDAG's which upset the type checker). I'm going to fix this next, but can't bring myself to do it in the same commit.
Swift SVN r4617
At the top level, if 'operator' is followed by 'infix', 'prefix', or 'postfix', consider it a contextual keyword, and parse an operator decl following it that looks like:
operator {infix|postfix|prefix} <+> {
attributes…
}
Prefix and postfix operator decls currently admit no attributes. Infix operators have 'associativity {left|right|none}' and 'precedence <int>' attributes.
This patch implements parsing for operator declarations but does not yet attach the declared attributes to func decls for the operators.
Swift SVN r4596
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
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
This new syntax aims to be closer to the declaration syntax. For
example, to call this method:
func performSelector(_ : SEL) withObject(obj1 : id) { }
one would use
target.performSelector("doThis:") withObject(object)
The additional selector pieces (e.g., withObject(object)) occur on the
same line; otherwise, they are taken as a separate statement. However,
one can use ':' as a continuation character at the beginning of the
next line to continue the message send, e.g.,
target.performSelector("doThis:")
:withObject(object)
For the 3-argument version, one could use, e.g.,
target.performSelector("doThis:") withObject(object1) withObject(object2)
or
target.performSelector("doThis:")
:withObject(object1) withObject(object2)
or
target.performSelector("doThis:")
:withObject(object1)
:withObject(object2)
depending on the width of your screen.
Note that I've tweaked the parsing of case statements slightly to
accommodate this change, by requiring that the ':' that follows a case
statement not start a new line. Thus,
case foo:
is okay, but
case foo
:
is not. This is mostly paranoia, so that
case target.performSelector("sel"):
is "obviously" a simple method invocation in the case, while
case target.performSelector("sel")
:withObject(object):
is "obviously" a two-argument method invocation in the case.
This syntax has some positives, such as similarity with the function
declaration syntax and being a fairly clean extension of the "normal"
Swift method call syntax. It also has some negatives: we have our
first continuation character (':'), the syntax for constructors is
(again) a bit unfortunate
new NSURL(initWithString="http://www.apple.com")
and it's not clear how to invoke a variadic method with this syntax
without, say, burying the additional arguments in the last argument
(which is currently not permitted), e.g.,
NSString.alloc().initWithFormat("blah") locale(locale, arg1, arg2)
Swift SVN r4366
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
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
This requires a gross but simple contract between pattern parsing and C
for loop parsing where pattern parsing will gracefully back out if and
only if we have a potential C for loop pattern AND assignment is
detected in the pattern (which isn't otherwise allowed outside of the
context of func decls).
If we ever want "for (((;;)))" to work, then this we'll need to
implement the fully general arbitrary token lookahead. But for now, the
common C style "just works".
Swift SVN r3831
We have no intention of ever supporting actual semicolon statements
(separators, statements no), nor do we ever want to because that would
mean the behavior of the program would potentially change if semicolons
were naively removed.
This patch tracks the trailing semicolon now in the decl/expr/stmt,
which will enable someone to write a good "swift indent" tool in the
future.
Swift SVN r3824
Instead of writing in an awkward special case for SemiStmt in ParseStmt, apply the existing semicolon-eating syntax in ParseDecl for types to the toplevel. Suggested by Jordan re: r3336.
Swift SVN r3342
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
implementing rdar://11360347 / 11349750. C-style for loops could be
further enhanced by allowing a comma-separated list of statements in
the increment, but this isn't something I plan to do in the short term.
Swift SVN r1713
