Commit Graph

8 Commits

Author SHA1 Message Date
Chris Lattner
d05205ba8b move trailing closure tests into the expr/closures directory instead of being
in its own test dir.  NFC.


Swift SVN r15017
2014-03-14 00:30:43 +00:00
Joe Pamer
81690590c4 When type checking a closure expression, don't bail if a semantic error is encountered when validating the closure's parameter list. At best, this means we won't be able to point out any potential errors in the return-type annotation. At worst, it could leave us with a malformed closure type.
Swift SVN r14529
2014-02-28 19:21:24 +00:00
Joe Pamer
c9bd295533 When contextualizing closure expressions wrapped in auto closures, ensure that the inner closure's parent context is properly adjusted to reflect the auto closure's newly adjusted parent context.
Swift SVN r14482
2014-02-27 22:29:35 +00:00
Doug Gregor
faf1c45d14 Shuffle the files in the testsuite a bit to try to reflect language structure.
There's a lot more work to do here, but start to categorize tests
along the lines of what a specification might look like, with
directories (chapters) for basic concepts, declarations, expressions,
statements, etc.


Swift SVN r9958
2013-11-05 15:12:57 +00:00
Doug Gregor
63ff23147f Implement another new closure syntax.
In this syntax, the closure signature (when present) is placed within
the braces and the 'in' keyword separates it from the body of the
closure, e.g.,

      magic(42, { (x : Int, y : Int) -> Bool in
        print("Comparing \(x) to \(y).\n")
        return y < x
      })

When types are omitted from the parameter list, one can also drop the
parentheses, e.g.,

      magic(42, { x, y -> Bool in
        print("Comparing \(x) to \(y).\n")
        return y < x
      })

The parsing is inefficient and recovers poorly (in part because 'in'
is a contextual keyword rather than a real keyword), but it should
handle the full grammar. A number of tests, along with the whitepaper
and related rational documents, still need to be updated. Still, this
is the core of <rdar://problem/14004323>.



Swift SVN r6105
2013-07-10 01:15:15 +00:00
Doug Gregor
fab984aeae Test and improve parser error recovery for closures.
Swift SVN r5203
2013-05-17 16:39:20 +00:00
Doug Gregor
6e64ca66f0 Treat '|' as a delimiter while parsing the signature of a closure.
'|' 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
2013-05-17 16:02:44 +00:00
Doug Gregor
ce3fe3ae92 Implement Ruby-inspired closure syntax.
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
2013-05-14 05:17:10 +00:00