Commit Graph

6 Commits

Author SHA1 Message Date
Chris Lattner
31c01eab73 Change the meaning of "if let x = foo()" back to Xcode 6.4 semantics. The compiler
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
2015-04-30 04:38:13 +00:00
Chris Lattner
20f8f09ea8 Land: <rdar://problem/19382905> improve 'if let' to support refutable patterns and untie it from optionals
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
2015-03-15 07:06:22 +00:00
Dmitri Hrybenko
6cad796ec8 Annotate compiler crasher tests so that the tests succeed reliably when
the compiler is built without assertions

Swift SVN r24061
2014-12-20 09:42:59 +00:00
Dmitri Hrybenko
1eea220932 Use one module cache directory for all the lit tests to speed them up
Doing so is safe even though we have mock SDK.  The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).

This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.

This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple.  I
fixed the tests where I noticed this issue.

rdar://problem/19125022

Swift SVN r23683
2014-12-04 11:21:48 +00:00
Chris Willmore
513b05c283 compiler_crashers: Use %target-swift-frontend instead of %swift -sdk %sdk
This fixes compiler_crashers tests that use the ObjC interface on
iOS hardware SDKs.

Swift SVN r23458
2014-11-20 00:32:59 +00:00
Chris Willmore
4e1fa4a63f Import the swift-compiler-crashes test suite.
Add all compiler crash tests to the validation-test/compiler_crashers
subdirectory. Add a RUN: line to each test case according to the current
behavior of the Swift compiler.

Swift SVN r23418
2014-11-19 01:27:58 +00:00