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
Cast operators no longer have precedence below all operators, but they still end sequence expression parsing because of the type production on their right sides.
Swift SVN r5572
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
Trailing closure syntax allows one to write a closure following any
other postfix expression, which passes the closure to that postfix
expression as an arguments. For example:
sort(fruits) { |lhs, rhs|
print("Comparing \(lhs) to \(rhs)\n")
return lhs > rhs
}
As a temporary limitation to work around the ambiguity with
if foo { ... } { ... }
we require trailing closures to have an explicit parameter list, e.g.,
if foo { || ... } { ... }
Swift SVN r5210
The description of identifiers got long enough that it makes sense to break operators out into their own subsection. Also, I snuck '@' into the operator character set.
Swift SVN r5006
For example, this allows:
var window = new NSWindow.(initWithContentRect:NSRect(100, 100, 800, 630)
styleMask:Int(NSTitledWindowMask|NSClosableWindowMask|NSResizableWindowMask)
backing:NSBackingStoreType(NSBackingStoreBuffered)
defer:false)
Swift SVN r4315
Introduce a second syntax for method calls that better describes
messages with multiple selector pieces, e.g.,
undoManager.(registerUndoWithTarget:this
selector:"setItemName:"
object:nameSetter)
Note that we're also allowing ':' as a separator for normal keyword
arguments. The intent is to drop the use of '=' for normal keyword
arguments, but that will be a separate change affecting a number of
test cases.
Swift SVN r4313
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
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
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
rdar://12315571
Allow a function to be defined with this syntax:
func doThing(a:Thing) withItem(b:Item) -> Result { ... }
This allows the keyword names in the function type (in this case
`(_:Thing, withItem:Item) -> Result`) to differ from the names bound in the
function body (in this case `(a:Thing, b:Item) -> Result`, which allows
for Cocoa-style `verbingNoun` keyword idioms to be used without requiring
those keywords to also be used as awkward variable names. In addition
to modifying the parser, this patch extends the FuncExpr type by replacing
the former `getParamPatterns` accessor with separate `getArgParamPatterns`
and `getBodyParamPatterns`, which retrieve the argument name patterns and
body parameter binding patterns respectively.
Swift SVN r3098
Introduce a '.metatype' form in the syntax and do some basic
type-checking that I probably haven't done right. Change
IR-generation for that and GetMetatypeExpr to use code that
actually honors the dynamic type of an expression.
Swift SVN r3053