Create a scope for each case block to contain bindings from its patterns, and invoke addVarsToScope after parsing case label patterns to introduce vars into that scope. Refactor addVarsToScope to use an ASTWalker so it finds pattern vars embedded in expr patterns.
Swift SVN r5899
Parse 'var', '_', and 'is' pattern forms at the top level of a matching pattern context. Keep track of VarPatternDepth in the parser state and raise an error if 'var' appears in a 'var'.
Swift SVN r5839
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
Currently not only we insert names in non-resolvable scopes, but every
overloaded name gets stored only once (the last one wins). Everything just
happens to work, because we never do name lookup in these scopes.
I also added a ScopeKind to every Scope (instead of just adding the bit --
isResolvableScope), because this provides a better debugging experience, and
centralizes knowledge about what scope kind is resolvable in the function
isResolvableScope(ScopeKind).
Swift SVN r5822
grammar description in LangRef and the parser to expose a new stmt-control-transfer.
- remove obsolete comment in ParseStmt.cpp talking about stmt-brace.
No behavior change.
Swift SVN r5809
A single case block can have one or more 'case ...:' labels. 'case' labels contain patterns instead of exprs. 'default:' is a funny spelling for 'case _:'. Change the CaseStmt representation and rip out all the parsing, type-checking, and SILGen built off the old representation.
Swift SVN r5795
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
Parse '=' as a binary operator with fixed precedence, parsing it into a temporary UnsequencedAssignExpr that gets matched to operands and turned into an AssignExpr during sequence expr folding. This makes '=' behave like library-defined assignment-like binary operators.
This temporarily puts '=' at the wrong precedence relative to 'as' and 'is', until 'as' and 'is' can be integrated into sequence parsing as well.
Swift SVN r5508
Change AssignStmt into AssignExpr; this will make assignment behave more consistently with assignment-like operators, and is a first step toward integrating '=' parsing with SequenceExpr resolution so that '=' can obey precedence rules. This also nicely simplifies the AST representation of c-style ForStmts; the initializer and increment need only be Expr* instead of awkward Expr*/AssignStmt* unions.
This doesn't actually change any user-visible behavior yet; AssignExpr is still only parsed at statement scope, and typeCheckAssignment is still segregrated from the constraint checker at large. (In particular, a PipeClosureExpr containing a single assign expr in its body still doesn't use the assign expr to resolve its own type.) The parsing issue will be addressed by handling '=' during SequenceExpr resolution. typeCheckAssignment can hopefully be reworked to work within the constraint checker too.
Swift SVN r5500
This moves trailing closures from expr-postfix up to the level of
expr, and introduces an intermediate level (expr-basic) for places
that need to parse expressions followed by curly braces, such as
if/while/switch/for. Trailing closures are still restricted to occur
after expr-postfix, although the parser itself parses a slightly more
general and then complains if it got more than an expr-postfix.
Swift SVN r5256
mode for normal .swift files. We basically parse batches of non-sil function
decls, type check them as a batch, then process any SIL functions. This allows
us to have mutually recursive types and other things that are fully sema'd and
that are referenced by SIL functions, without involving SIL functions too
intimately with type checking.
This does mean that SIL functions can't forward reference types, oh well.
Swift SVN r5243
'|' is part of the character set for operators, but within the
signature of a closure we need to treat the first non-nested '|' as
the closing delimiter for the closure parameter list. For example,
{ |x = 1| 2 + x}
parses with the default value of '1' for x, with the body 2 + x. If
the '|' operator is needed in the default value, it can be wrapped in
parentheses:
{ |x = (1|2)| x }
Note that we have problems with both name binding and type checking
for default values in closures (<rdar://problem/13372694>), so they
aren't actually enabled. However, this allows us to parse them and
recover better in their presence.
Swift SVN r5202
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
