This will be necessary for things like typo-correction, but currently
serves no purpose because all of our diagnostics are token-based. It's
going to be the base range type for Swift fix-its, though, so I thought I'd
get it in place now.
Swift SVN r4750
Fix array/dictionary literal parsing robustness by consolidating and improving
the parsing of lists in general (tuples/array/dictionary literals, attribute
lists, statement lists, declaration lists, etc).
Missing commas in tuple/array/dictionary literals or declaration attributes
are now detected, reported, and recovered from.
Premature ellipsis in tuples are now detected, reported, and recovered from.
Swift SVN r4631
NOTE: A nice side effect of this change is that f(x:&y) and g(x:<) parse
correctly regardless of whitespace, unlike f(x=&y) and g(x=<).
Swift SVN r4579
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
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
'super.constructor' shouldn't be referenceable without being called, and 'super.constructor(...)' shouldn't return a value. Require super.constructor expressions to be called at parse time, and wrap the call expression in a new RebindThisInConstructorExpr that represents consuming the delegated-to constructor by using it to reassign 'this'. This should theoretically allow super.constructor to an ill-behaved self-modifying ObjC class to work. It's also necessary to support delegating constructors of value types.
Swift SVN r4326
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
Replace the more specific Super*RefExpr nodes with a single SuperRefExpr that resolves members of 'this' relative to its superclass. Add an OtherConstructorDeclRefExpr for referring to a constructor as called from another constructor, and use it to represent resolved 'super.constructor' expressions. (It should also be able to represent delegating constructors for free, if we decide we want to add syntax for that.)
Swift SVN r4286
Enable operator functions to be referred to by name as, e.g., (+), (+=), etc. Unary/binary ambiguities are resolved via type context. Prefix/postfix unary ambiguities aren't resolved. References to assignment operators produce plain [byref] functions.
Swift SVN r4274
This node represents a type parameter list application in an unresolved expr context. The type checker will use these to explicitly bind type variables of generic types.
Swift SVN r4046
When parsing an expression, if we see the production [[identifier '<']], use the following heuristic to choose whether to parse it as a type list or as an operator expression:
- Speculatively parse the subsequent production as a type parameter list.
- If the parse succeeds, examine the token after the closing '>'. If it is one of the following:
l_paren_following
l_square_following
r_paren
r_square
l_brace
r_brace
comma
semicolon
period
then accept the parse as a type list.
- If the parse fails, or if the type list is not followed by one of those tokens, reject the type list and parse as an operator expression.
This only implements the parsing rule. The type parameters are just dropped on the floor--the AST representation and Sema changes are forthcoming. Encouragingly, no test or library code appears to be broken by this rule.
Swift SVN r4044
Add support to the constraint checker for typechecking UnresolvedSuperMemberRef expressions and constructing SuperMemberRef or SuperCall expressions as appropriate. We’ll also need a GenericSuperMemberRefExpr to refer to properties of generic supertypes, but in the interests of demo expedience I’m leaving that case partially-implemented for now.
Swift SVN r4020
Analyze an expression of the form [<tuple contents>] into a call to T.convertFromArrayLiteral(<tuple contents>) for some T conforming to an ArrayLiteralConvertible protocol. Because of some limitations in the constraint checker and protocol conformance checkers, it currently does an ad-hoc conformance check using member constraints. It also currently fails to typecheck for generic container types, and does not provide a default fallback to 'T[]' if unable to deduce a better type from context.
Swift SVN r3953
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
Set up AST nodes for 'super.<identifier>', 'super.constructor', and 'super[<expr>]' expressions, and implement parsing for them without any sema or backend support.
Swift SVN r3847
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
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
static method to call it, to make it more explicit what is happening. Avoid
using TypeLoc::withoutLoc for function definitions; instead, just use an empty
TypeLoc.
Swift SVN r2606
