early instead of leaving them to TypeCheckExpr to find in an arbitrary "late"
place in type checking. This gives us better (more localized) diagnostics and
reduces downstream errors when a pattern is malformed. This is the
foundation to produce more specific errors than "invalid pattern"
Swift SVN r26802
- Enhance PBD with a whereExpr/elseStmt field to hold this.
- Start parsing the pattern of let/var decls as a potentially refutable pattern. It becomes
a semantic error to use a refutable pattern without an 'else' (diagnostics not in place yet).
- Change validatePatternBindingDecl to use 'defer' instead of a goto to ensure cleanups on exit.
- Have it resolve the pattern in a PBD, rewriting it from expressions into pattern nodes when valid.
- Teach resolvePattern to handle TypedPatterns now that they can appear (wrapping) refutable patterns.
- Teach resolvePattern to handle refutable patterns in PBD's without initializers by emitting a diagnostic
instead of by barfing, fixing regressions on validation tests my previous patch caused, and fixing
two existing validation test crashers.
Sema, silgen, and more tests coming later.
Swift SVN r26706
In an existential context, allow 'case Enum.Case:' by implicitly introducing a cast pattern, treating it as 'case Enum.Case as Enum:'. This will be important for the error handling design, where we want ErrorType-conforming enums to be pattern-matchable out of an ErrorType existential using 'catch' patterns.
Swift SVN r25968
This introduces a new pattern, spelled "x?" which is sugar for
matching ".Some(x)". It also changes the parser slightly so that
_ (the discard expr) is parsed as a unary expr instead of as an
expr. This allows it to have postfix ? after it, which is important
in pattern contexts to support "case _?:".
Swift SVN r25907
In a situation like::
enum Foo {
case Bar(bar: Int)
}
switch foo {
case let .Bar(bar):
use(bar)
}
It's extremely unlikely anyone expects 'bar' to have type '(bar: Int)' rather than 'Int', especially because we try to eliminate single-element tuple types pretty much everywhere else. Put in a hack so that, when we see a paren pattern as the payload subpattern of an enum case pattern, and the payload has a single-element tuple type, we transform the paren pattern into a tuple pattern, which semantically matches off the label. Fixes rdar://problem/18923473, and a lot of dupes.
Swift SVN r25541
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
When checking an isa pattern that requires either collection
downcasting or bridging through an Objective-C class (e.g.,
"is String" or "is Dictionary<String, Int>"), form a conditional
downcast and place it in an expression pattern.
With this change, we can test for these cases (with "is") but we can't
capture the value produced on success (e.g., for "let str as
String"). This is a first small step toward <rdar://problem/17408934>.
Swift SVN r19070
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
