Resolve conflicts with upstream

Author: PatrickPijnappel

.gitignore

@@ -16,7 +16,7 @@
 # Byte compiled python modules.
 *.pyc
 # vim swap files
-.*.swp
+.*.sw[a-z]
 .sw?
 
 #==============================================================================#
@@ -39,3 +39,4 @@ docs/_build
 #==============================================================================#
 CMakeCache.txt
 CMakeFiles
+.atom-build.json

.pep8

@@ -1,2 +1,2 @@
 [flake8]
-filename = *.py,Benchmark_Driver,Benchmark_DTrace.in,Benchmark_GuardMalloc.in,Benchmark_RuntimeLeaksRunner.in,build-script,gyb,line-directive,ns-html2rst,recursive-lipo,rth,submit-benchmark-results,update-checkout,viewcfg
+filename = *.py,80+-check,Benchmark_Driver,Benchmark_DTrace.in,Benchmark_GuardMalloc.in,Benchmark_RuntimeLeaksRunner.in,build-script,gyb,line-directive,mock-distcc,ns-html2rst,recursive-lipo,rth,split-generated-tests,submit-benchmark-results,update-checkout,viewcfg

CHANGELOG.md

@@ -1,6 +1,149 @@
+Note: This is in reverse chronological order, so newer entries are added to the top.
 
 Swift 3.0
--------
+---------
+
+* [SE-0071](https://github.com/apple/swift-evolution/blob/master/proposals/0071-member-keywords.md):
+  "Allow (most) keywords in member references" is implemented.  This allows the
+  use of members after a dot without backticks, e.g. "foo.default".
+
+* [SE-0057](https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md):
+  Objective-C lightweight generic classes are now imported as generic types
+  in Swift. Because Objective-C generics are not represented at runtime,
+  there are some limitations on what can be done with them in Swift:
+
+  - If an ObjC generic class is used in a checked `as?`, `as!`, or `is` cast,
+    the generic parameters are not checked at runtime. The cast succeeds if the
+    operand is an instance of the ObjC class, regardless of parameters.
+
+    ```swift
+    let x = NSFoo<NSNumber>(value: NSNumber(integer: 0))
+    let y: AnyObject = x
+    let z = y as! NSFoo<NSString> // Succeeds
+    ```
+
+  - Swift subclasses can only inherit an ObjC generic class if its generic
+    parameters are fully specified.
+
+    ```swift
+    // Error: Can't inherit ObjC generic class with unbound parameter T
+    class SwiftFoo1<T>: NSFoo<T> { }
+
+    // OK: Can inherit ObjC generic class with specific parameters
+    class SwiftFoo2<T>: NSFoo<NSString> { }
+    ```
+
+  - Swift can extend ObjC generic classes, but the extensions cannot be
+    constrained, and definitions inside the extension do not have access to
+    the class's generic parameters.
+
+    ```swift
+    extension NSFoo {
+      // Error: Can't access generic param T
+      func foo() -> T {
+        return T()
+      }
+    }
+
+    // Error: extension can't be constrained
+    extension NSFoo where T: NSString {
+    }
+    ```
+
+  - Foundation container classes `NS[Mutable]Array`, `NS[Mutable]Set`, and
+    `NS[Mutable]Dictionary` are still imported as nongeneric classes for
+    the time being.
+
+* As part of the changes for SE-0055 (see below), the *pointee* types of
+  imported pointers (e.g. the `id` in `id *`) are no longer assumed to always
+  be `_Nullable` even if annotated otherwise. However, an implicit or explicit
+  annotation of `_Null_unspecified` on a pointee type is still imported as
+  `Optional`.
+
+* [SE-0055](https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md):
+  The types `UnsafePointer`, `UnsafeMutablePointer`,
+  `AutoreleasingUnsafeMutablePointer`, `OpaquePointer`, `Selector`, and `Zone`
+  (formerly `NSZone`) now represent non-nullable pointers, i.e. pointers that
+  are never `nil`. A nullable pointer is now represented using `Optional`, e.g.
+  `UnsafePointer<Int>?` For types imported from C, non-object pointers (such as
+  `int *`) now have their nullability taken into account.
+
+  One possible area of difficulty is passing a nullable pointer to a function
+  that uses C variadics. Swift will not permit this directly, so as a
+  workaround please use the following idiom to pass it as a pointer-sized
+  integer value instead:
+
+  ```swift
+  unsafeBitCast(nullablePointer, to: Int.self)
+  ```
+
+* [SE-0046] (https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md) Function parameters now have consistent labelling across all function parameters. With this update the first parameter declarations will now match the existing behavior of the second and later parameters. This change makes the language simpler.
+
+    Functions that were written and called as follows
+    ```swift
+      func foo(x: Int, y: Int) {
+      }
+      foo(1, y: 2)
+
+      func bar(a a: Int, b: Int) {
+      }
+      bar(a: 3, b: 4)
+    ```
+    will now be written as (to achieve the same behavior):
+    ```swift
+        func foo(_ x: Int, y: Int) {}
+        foo(1, y: 2)
+        func bar(a: Int, b: Int) {}
+        bar(a: 3, b: 4)
+    ```
+
+* [SE-0037](https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md)
+  Comments are now treated as whitespace when determining whether an operator is
+  prefix, postfix, or binary. For example, these now work:
+  ```swift
+    if /*comment*/!foo { ... }
+    1 +/*comment*/2
+  ```
+
+  This also means that comments can no longer appear between a unary operator
+  and its argument.
+  ```swift
+    foo/* comment */! // no longer works
+  ```
+
+  Any parse errors resulting from this change can be resolved by moving the
+  comment outside of the expression.
+
+* [SE-0031](https://github.com/apple/swift-evolution/blob/master/proposals/0031-adjusting-inout-declarations.md) The location of the inout attribute has been moved to after the `:` and before the parameter type.
+```swift
+  func foo(inout x: Int) {
+  }
+```
+  will now be written as:
+```swift
+  func foo(x: inout Int) {
+  }
+```
+
+* [SE-0053](https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md) `let` is no longer accepted as a parameter attribute for functions. The compiler provides a fixit to remove it from the function declaration.
+
+* [SE-0003](https://github.com/apple/swift-evolution/blob/master/proposals/0003-remove-var-parameters.md) `var` is no longer accepted as a parameter attribute for functions. The compiler provides a fixit to create a shadow copy in the function body.
+```swift
+  func foo(var x: Int) {
+  }
+```
+  will now be written as:
+```swift
+  func foo(x: Int) {
+    var x = x
+  }
+```
+
+* The "none" members of imported NS_OPTIONS option sets are marked as unavailable
+  when they are imported.  Use [] to make an empty option set, instead of a None member.
+
+* [SE-0043](https://github.com/apple/swift-evolution/blob/master/proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.md)
+  landed, adding the ability to declare variables in multiple patterns in cases.
 
 * Renamification landed, so the Clang importer imports ObjC symbols
   substantially differently.  *Someone should expand on this point.*
@@ -14,7 +157,7 @@ Swift 3.0
     typealias StringDictionary<T> = Dictionary<String, T>
     typealias IntFunction<T> = (T) -> Int
     typealias MatchingTriple<T> = (T, T, T)
-    typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)
+    typealias BackwardTriple<T1, T2, T3> = (T3, T2, T1)
 ```
   etc.
 
@@ -61,6 +204,13 @@ Swift 3.0
         }
     }
     ```
+* Throwing closure arguments of a rethrowing function may now be optional. For example:
+
+    ```swift
+    func executeClosureIfNotNil(closure: (() throws -> Void)?) rethrows {
+        try closure?()
+    }
+    ```
 
 Swift 2.2
 ---------
@@ -77,7 +227,7 @@ Swift 2.2
   The `typealias` keyword is still allowed (but deprecated and produces a warning)
   in Swift 2.2. This warning will become an error in Swift 3.0.
 
-* Curried function syntax has been deprecated, and is slated to be removed in 
+* Curried function syntax has been deprecated, and is slated to be removed in
   Swift 3.0.
 
 * The `++` and `--` operators have been deprecated, and are slated to be removed in
@@ -94,12 +244,12 @@ Swift 2.2
     ```
 
   should move to being written as:
-  
+
     ```swift
     foo(x.0, x.b)
     ```
 
-  For more information and rationale, see 
+  For more information and rationale, see
   [SE-0029](https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md).
 
 * New `#file`, `#line`, `#column`, and `#function` expressions have been introduced to
@@ -217,7 +367,7 @@ Swift 2.2
 
       let buttonFactory = UIButton.init(type:)
    ```
-   
+
   For more information, see [SE-0021](https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md).
 
 * There is a new build configuration function, `#if swift(>=x.y)`, which
@@ -244,14 +394,14 @@ Swift 2.2
    ```swift
       let sel = #selector(insertSubview(_:aboveSubview:)) // sel has type Selector
    ```
-   
+
   Along with this change, the use of string literals as selectors has
   been deprecated, e.g.,
 
   ```swift
       let sel: Selector = "insertSubview:aboveSubview:"
   ```
-   
+
   Generally, such string literals should be replaced with uses of
   `#selector`, and the compiler will provide Fix-Its that use
   `#selector`. In cases where this is not possible (e.g., when referring
@@ -261,7 +411,7 @@ Swift 2.2
   ```swift
       let sel = Selector("propertyName")
   ```
-   
+
   Note that the compiler is now checking the string literals used to
   construct Selectors to ensure that they are well-formed Objective-C
   selectors and that there is an `@objc` method with that selector.
@@ -790,8 +940,8 @@ Swift 2.2
   value for the enum to be stored indirectly, allowing for recursive data
   structures to be defined. For example:
 
-  ```swift  
-  enum List<T> {
+  ```swift
+    enum List<T> {
     case Nil
     indirect case Cons(head: T, tail: List<T>)
   }
@@ -1039,7 +1189,7 @@ Swift 2.2
   needs to be written as:
 
   ```swift
-  var (a,b) : (Int, Float) = foo()
+  var (a, b) : (Int, Float) = foo()
   ```
 
   if an explicit type annotation is needed. The former syntax was ambiguous
@@ -1835,10 +1985,10 @@ Swift 2.2
 2014-10-09 [Roughly Xcode 6.1, and Swift 1.1]
 ----------
 
-* `HeapBuffer<Value,Element>`, `HeapBufferStorage<Value,Element>`, and
+* `HeapBuffer<Value, Element>`, `HeapBufferStorage<Value, Element>`, and
   `OnHeap<Value>` were never really useful, because their APIs were
   insufficiently public.  They have been replaced with a single class,
-  `ManagedBuffer<Value,Element>`.  See also the new function
+  `ManagedBuffer<Value, Element>`.  See also the new function
   `isUniquelyReferenced(x)` which is often useful in conjunction with
   `ManagedBuffer`.
 
@@ -1941,7 +2091,7 @@ Swift 2.2
     ```swift
     enum Foo: Int { case A = 0, B = 1, C = 2 }
     let foo = Foo(rawValue: 2)! // formerly 'Foo.fromRaw(2)!'
-    println(foo.rawValue)  // formerly 'foo.toRaw()'
+    println(foo.rawValue) // formerly 'foo.toRaw()'
     ```
 
 2014-09-02
@@ -2646,7 +2796,7 @@ Swift 2.2
 
   In many common cases, this will just work.  Unfortunately, values
   are returned from `CF`-style APIs in a wide variety of ways, and
-  unlike Objective C methods, there simply isn't enough consistency
+  unlike Objective-C methods, there simply isn't enough consistency
   for Swift to be able to safely apply the documented conventions
   universally.  The framework teams have already audited many of the
   most important `CF`-style APIs, and those APIs should be imported
@@ -3875,15 +4025,15 @@ Swift 2.2
 
     ```swift
     func swap<T>(a : @inout T, b : @inout T) {
-      (a,b) = (b,a)
+      (a, b) = (b, a)
     }
     ```
 
   You are now required to write:
 
     ```swift
     func swap<T>(inout a : T, inout b : T) {
-      (a,b) = (b,a)
+      (a, b) = (b, a)
     }
     ```
 
@@ -4744,8 +4894,8 @@ Swift 2.2
 * Array and dictionary literals allow an optional trailing comma:
 
     ```swift
-    var a = [ 1, 2, ]
-    var d = [ "a": 1, "b": 2, ]
+    var a = [1, 2,]
+    var d = ["a": 1, "b": 2,]
     ```
 
 2013-10-16