instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
pattern, and can be chained together in conditions just like our other 'if let'
constructs. This only adds functionality, it doesn't change anything yet.
Swift SVN r27932
Now we bind the defer body into a ClosureExpr and emit it at the point of
the defer. At any exit points out of the controlled region, we emit a call
to the closure.
This should cover any problems where expressions cannot be emitted multiple times.
However, this is dramatically more complex than the obvious implementation, so I
hope this patch can be reverted.
Swift SVN r27767
We warn like this:
t.swift:3:12: warning: 'let' pattern has no effect; sub-pattern didn't bind any variables
case let .Bar: println("bar")
^~~ ~~~~
Swift SVN r27747
Change all uses of "do { ... } while <cond>" to use "repeat" instead.
Rename DoWhileStmt to RepeatWhileStmt. Add diagnostic suggesting change
of 'do' to 'repeat' if a condition is found afterwards.
<rdar://problem/20336424> rename do/while loops to repeat/while & introduce "repeat <count> {}" loops
Swift SVN r27650
by tweaking parsing logic to handle a common error case with a nice diagnostic + fixit. We now produce:
x.swift:4:29: error: binding ended by previous 'where' clause; use 'let' to introduce a new one
if let y? = x where y == 0, z? = x where z == 0 {
^
let
Swift SVN r27452
We only require one of the patterns in a multi-pattern PBD to be conditional
as part of the swift 1 migation. Relax the requirements to allow unconditional
bindings next to conditional ones. This required moving some logic from the parser
to sema time.
Swift SVN r26987
- Implement SILGen for conditional multi-pattern PBD's.
- Have the type checker check where clauses on PBDs.
- Change the AST to represent complex if/let PBD's with
composed PBDs instead of breaking them down. For example,
represent:
if let x? = foo(), y? = bar() where x == y {
as a single PBD in a StmtCondition instead of representing
it as three entries in the condition.
The later change is good for AST/source fidelity as well as providing
a cheap way to exercise all the logic I'm building.
Swift SVN r26959
and refutable pattern bindings without an initializer.
- Enhance ASTDumper to dump where/else clauses on PBDs.
- Merge if/let conditional PBD logic into the mainline logic now that they are all
potentially conditional (more simplifications coming for this)
add tests for the fixits, which exercise the earlier SourceRange enhancments, e.g.:
x.swift:3:5: error: refutable pattern match can fail; add an else {} to handle this condition
let o? = a
^~
else {}
Swift SVN r26751
to find variables, enabling it to work with refutable patterns in
addition to nonrefutable ones. This allows eliminating some special
case code in the parser, NFC.
Swift SVN r26686
This patch also introduces some SILGen infrastructure for
dividing the function into "ordinary" and "postmatter"
sections, with error-handling-like stuff going into the
final section. Currently, this is largely undermined by
SILBuilder, but I'm going to fix that in a follow-up.
Swift SVN r26422
- Strength reduce isAtStartOfBindingName() to just check for
identifier or _ and inline into its two callers.
- Rename Token::isIdentifierOrNone to isIdentifierOrUnderscore.
- Teach InVarOrLetPattern about matching patterns, so that the
parser knows when it is parsing an expression as a matching
pattern but is not yet inside a let/var pattern.
- Use newfound knowledge of matching patterns to refine handling
of unexpected let/var when parsing an expression, but not in a
pattern context, slightly improving QoI in invalid cases.
Swift SVN r26172
This is still a subject of discussion on swift-dev, but it seems like clearly the right
way to go to me. If it turns out that this isn't a good direction, I'll revert this and
subsequent patches built on top of it.
Swift SVN r26168
This was because the ambiguity between c-style and foreach loops wasn't being
properly handled. Use the canParsePattern() logic to handle this in full
generality.
Since that logic was unused, dust it off and clean it up a bit. Similarly,
remove some old vestigates of default argument parsing in tuples and
old-syntax array handling.
Swift SVN r26164
duplicated by the InVarOrLetPattern state in the Parser object. Beef
InVarOrLetPattern up so that we can remove it.
NFC except that we now reject pointless let patterns in foreach loops,
similar to how we reject var patterns inside of let patterns.
Swift SVN r26163
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
conjunction with .fixItInsert(). As such, introduce a helper named
.fixItInsertAfter() that does what we all want. Adopt this in various
places around the compiler. NFC.
Swift SVN r26147
For now, we assume that 'while' after the braces starts
a do/while rather than being an independent statement.
We should disambiguate this, or better, remove do/while.
Tests later.
Swift SVN r26079
Corrected several places where compiler generated AST nodes were not properly
marked as implicit.
For interpolated strings also fixed string segment locations and made sure
the first and last segments are preserved in AST even if they are empty.
Swift SVN r25983
