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
auto-completing @attributes. By delaying the handling of code completion token after the entire decl being parsed, we know
what are the targets of the attribute to finishe, thus, only suggesting those applicable attributes.
Swift SVN r25938
If '{' is encountered immediately after 'if', assume that the condition
is missing. Apply the same treatment to while, do-while, for-in, and
switch. This way we're not trying to re-parse, backtrack, repurpose
misparsed closure bodies, etc. in those cases. Users who want to write a
condition that starts with '{' can wrap it in parens.
Addressing feedback re <rdar://problem/18940198>.
Swift SVN r25747
Otherwise we'll get all the way to IRGen and then try to emit them. And try
to reference them in serialization.
rdar://problem/19935034
Swift SVN r25567
This doesn't allow 'continue' out of an if statement for the same reason we don't
allow it on switch: we'd prefer people to write loops more explicitly.
Swift SVN r25565
un-type-annotated AnyObject binding in "if let", and allows general
patterns in if-let.
This also reverts some unrelated QoI improvements that went in with those
patches, but I'll add those back next.
Swift SVN r25507
closure, reparse it as a brace statement instead of attempting to
repurpose the closure body. Suppress diagnostics from the initial
condition parse until we're committed to that parse.
<rdar://problem/18940198> Fuzzing Swift: performTypeChecking(...) crashes in ContextualizeClosures::walkToExprPre(...): Assertion failed: "Incorrect parent decl context for closure"
Swift SVN r25438
two logically independent but related patches conflated together:
- Improve error recovery for malformed if/let conditions, particularly
when the user uses "," instead of &&. Add testcases for error recovery
requested by Jordan.
- Add a syntactic requirement that the pattern of an if/let condition be
a simple identifier or _. We allow slightly broader patterns here now,
but they will change in the future when refutable patterns are allowed.
It is best to be narrow and then open it up later so we can do a great
job of QoI then.
This includes the changes to the stdlib directory that I forgot to commit
with the patch the previous time.
Swift SVN r25408
- Improve error recovery for malformed if/let conditions, particularly
when the user uses "," instead of &&. Add testcases for error recovery
requested by Jordan.
- Add a syntactic requirement that the pattern of an if/let condition be
a simple identifier or _. We allow slightly broader patterns here now,
but they will change in the future when refutable patterns are allowed.
It is best to be narrow and then open it up later so we can do a great
job of QoI then.
Swift SVN r25371
Brace statement created for wrapping IfConfig inside TopLevelCodeDecl does not have
closing brace, so we should use the previous token’s location as right brace location.
Swift SVN r24797
