If we're under a 'var' pattern, reinterpret bare identifier exprs early on as variable bindings so we will be able to add them to the case scope.
Swift SVN r5898
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
Add a parseMatchingPattern method that just calls down to the expr parser and shoves the expr in an ExprPattern. We'll augment the expr parser with matching pattern productions soon.
Swift SVN r5833
Continue the LLVM tradition of passing 'this' to module-local static functions as an inscrutable single-capital-letter reference argument instead of a more descriptively named pointer argument.
Swift SVN r5821
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
Sub-patterns are now considered part of the enclosing pattern, so if the
parent pattern pointer is const, the child pointer will be too.
I changed the minimal number of files to make this work, but future code
should use "const Pattern *" when intended, and "Pattern *" only if they
intend to modify the pattern.
Swift SVN r5743
This commit implements closure syntax that places the (optional)
parameter list in pipes within the curly braces of a closure. This
syntax "slides" well from very simple closures with anonymous
arguments, e.g.,
sort(array, {$1 > $0})
to naming the arguments
sort(array, {|x, y| x > y})
to adding a return type and/or parameter types
sort(array, {|x : String, y : String| -> Bool x > y})
and with multiple statements in the body:
sort(array, {|x, y|
print("Comparing \(x) and \(y)\n")
return x > y
})
When the body contains only a single expression, that expression
participates in type inference with its enclosing expression, which
allows one to type-check, e.g.,
map(strings, {|x| x.toUpper()})
without context. If one has multiple statements, however, one will
need to provide additional type information either with context
strings = map(strings, {
return $0.toUpper()
})
or via annotations
map(strings, {|x| -> String
return x.toUpper()
}
because we don't perform inter-statement type inference.
The new closure expressions are only available with the new type
checker, where they completely displace the existing { $0 + $1 }
anonymous closures. 'func' expressions remain unchanged.
The tiny test changes (in SIL output and the constraint-checker test)
are due to the PipeClosureExpr AST storing anonymous closure arguments
($0, $1, etc.) within a pattern in the AST. It's far cleaner to
implement this way.
The testing here is still fairly light. In particular, we need better
testing of parser recovery, name lookup for closures with local types,
more deduction scenarios, and multi-statement closures (which don't
get exercised beyond the unit tests).
Swift SVN r5169
This simple refactor makes pattern-tuple-element available for re-use
in closure expressions. As a drive-by, diagnose non-final ellipses via
diagnose() rather than via assert(), the latter being considered
rather unfriendly. Also, take pains to restore AST invariants after
such an error.
Swift SVN r5163
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
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
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
Only functions support default values in their patterns. To quote: "Within a
function signature, patterns may also be given a default-value expression."
In other words, only functions are allowed default values.
This fixes: 13057022 "var (x : Int = 123, y : Int = 456)" doesn't init x and y
Swift SVN r3829
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
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
analysis for patterns.
Major changes:
1. We no longer try to compute the types of functions in the parser.
2. The type of a function always matches the type of the argument patterns.
3. Every FuncDecl now has a corresponding FuncExpr; that FuncExpr might not
have a body, though.
4. We now use a new class "ExprHandle" so that both a pattern and a type
can hold a reference to the same expression.
Hopefully this will be a more reasonable foundation for further changes to
how we compute the types of FuncDecls in generics and for the implementation
of type location information.
Swift SVN r2370
resolution. When we see a polymorphic function type, we substitute
"deducible generic parameter" types for each of the generic
parameters. Coercion then deduces those deducible generic parameter
types. This approach eliminates the confusion between the types used
in the definition (which must not be coerced) and the types used when
the generic function is referenced (which need to be coerced).
Note that there are still some terrible inefficiencies in our handling
of these types.
Swift SVN r2297
protocol conformance types, e.g., 'protocol<P, Q>'. A few things
people *might* want to scream about, or at least scrutinize:
- The parsing of the '<' and '>' is odd, because '<' and '>' aren't
tokens, but are part of the operator grammar. Neither are '>>',
'>>>', '<>', etc., which also come up and need to be parsed
here. Rather than turning anything starting with '<' or '>' into a
different kind of token, I instead parse the initial '<' or '>'
from an operator token and leave the rest of the token as the
remaining operator.
- The canonical form of a protocol-composition type is minimized by
removing any protocols in the list that were inherited by other
protocols in the list, then sorting it. If a singleton list is
left, then the canonical type is simply that protocol type.
- It's a little unfortunate that we now have two existential types
in the system (ProtocolType and ProtocolCompositionType), because
many places will have to check both. Once ProtocolCompositionTypes
are working, we should consider whether it makes sense to remove
ProtocolType.
Still to come: name lookup, coercions.
Swift SVN r2066
using the term "unresolved" in expressions for a while, and it fits
for types better than "dependent type."
The term "dependent type" will likely come back at some point to mean
"involves an archetype".
Swift SVN r1962
archetypes. Use this substitution when checking the
variable/function/subscript witnesses during protocol conformance.
This allows us to check the conforms-to relationship for the Range
protocol as we want to express it.
Swift SVN r1945
wrap it in an 'id' type in the standard library.
Also fix a bug noticed by inspection where initWithTake for
function types wasn't entering a cleanup for the taken value.
This probably doesn't matter for existing possibilities, but
it's potentially important under exceptions.
Swift SVN r1902
generic over the type of the base. By "generic" I mean that it's
looked up by prepending the word "Slice" to the name of the base
type.
Swift SVN r1464
and is just an unmanaged pointer. Also, introduce a basic swift.string type.
This is progress towards rdar://10923403 and strings. Review welcome.
Swift SVN r1349
