Merge pull request swiftlang#11 from minuscorp/typed-throws-dev

Update typed throws implementation

Author: minuscorp

CHANGELOG.md

@@ -4,26 +4,68 @@ CHANGELOG
 <details>
 <summary>Note: This is in reverse chronological order, so newer entries are added to the top.</summary>
 
-| Version                | Released   | Toolchain   |
-| :--------------------- | :--------- | :---------- |
-| [Swift 5.3](#swift-53) |            |             |
-| [Swift 5.2](#swift-52) | 2020-03-24 | Xcode 11.4  |
-| [Swift 5.1](#swift-51) | 2019-09-20 | Xcode 11.0  |
-| [Swift 5.0](#swift-50) | 2019-03-25 | Xcode 10.2  |
-| [Swift 4.2](#swift-42) | 2018-09-17 | Xcode 10.0  |
-| [Swift 4.1](#swift-41) | 2018-03-29 | Xcode 9.3   |
-| [Swift 4.0](#swift-40) | 2017-09-19 | Xcode 9.0   |
-| [Swift 3.1](#swift-31) | 2017-03-27 | Xcode 8.3   |
-| [Swift 3.0](#swift-30) | 2016-09-13 | Xcode 8.0   |
-| [Swift 2.2](#swift-22) | 2016-03-21 | Xcode 7.3   |
-| [Swift 2.1](#swift-21) | 2015-10-21 | Xcode 7.1   |
-| [Swift 2.0](#swift-20) | 2015-09-17 | Xcode 7.0   |
-| [Swift 1.2](#swift-12) | 2015-04-08 | Xcode 6.3   |
-| [Swift 1.1](#swift-11) | 2014-12-02 | Xcode 6.1.1 |
-| [Swift 1.0](#swift-10) | 2014-09-15 | Xcode 6.0   |
+| Version                   | Released   | Toolchain   |
+| :------------------------ | :--------- | :---------- |
+| [Swift Next](#swift-next) |
+| [Swift 5.3](#swift-53)    |            |             |
+| [Swift 5.2](#swift-52)    | 2020-03-24 | Xcode 11.4  |
+| [Swift 5.1](#swift-51)    | 2019-09-20 | Xcode 11.0  |
+| [Swift 5.0](#swift-50)    | 2019-03-25 | Xcode 10.2  |
+| [Swift 4.2](#swift-42)    | 2018-09-17 | Xcode 10.0  |
+| [Swift 4.1](#swift-41)    | 2018-03-29 | Xcode 9.3   |
+| [Swift 4.0](#swift-40)    | 2017-09-19 | Xcode 9.0   |
+| [Swift 3.1](#swift-31)    | 2017-03-27 | Xcode 8.3   |
+| [Swift 3.0](#swift-30)    | 2016-09-13 | Xcode 8.0   |
+| [Swift 2.2](#swift-22)    | 2016-03-21 | Xcode 7.3   |
+| [Swift 2.1](#swift-21)    | 2015-10-21 | Xcode 7.1   |
+| [Swift 2.0](#swift-20)    | 2015-09-17 | Xcode 7.0   |
+| [Swift 1.2](#swift-12)    | 2015-04-08 | Xcode 6.3   |
+| [Swift 1.1](#swift-11)    | 2014-12-02 | Xcode 6.1.1 |
+| [Swift 1.0](#swift-10)    | 2014-09-15 | Xcode 6.0   |
 
 </details>
 
+Swift Next
+----------
+
+* [SE-0287][]:
+
+  Implicit member expressions now support chains of member accesses, making the following valid:
+  
+  ```swift
+  let milky: UIColor = .white.withAlphaComponent(0.5)
+  let milky2: UIColor = .init(named: "white")!.withAlphaComponent(0.5)
+  let milkyChance: UIColor? = .init(named: "white")?.withAlphaComponent(0.5)
+  ```
+  
+  As is the case with the existing implicit member expression syntax, the resulting type of the chain must be the same as the (implicit) base, so it is not well-formed to write:
+  
+  ```swift
+  let cgMilky: CGColor = .white.withAlphaComponent(0.5).cgColor
+  ```
+  
+  (Unless, of course, appropriate `white` and `withAlphaComponent` members were defined on `CGColor`.)
+  
+  Members of a "chain" can be properties, method calls, subscript accesses, force unwraps, or optional chaining question marks. Furthermore, the type of each member along the chain is permitted to differ (again, as long as the base of the chain matches the resulting type) meaning the following successfully typechecks:
+  
+  ```swift
+  struct Foo {
+    static var foo = Foo()
+    static var bar = Bar()
+    
+    var anotherFoo: Foo { Foo() }
+    func getFoo() -> Foo { Foo() }
+    var optionalFoo: Foo? { Foo() }
+    subscript() -> Foo { Foo() }
+  }
+  
+  struct Bar {
+    var anotherFoo = Foo()
+  }
+
+  let _: Foo? = .bar.anotherFoo.getFoo().optionalFoo?.optionalFoo![]
+  ```
+
 Swift 5.3
 ---------
 
@@ -8071,6 +8113,7 @@ Swift 1.0
 [SE-0269]: <https://github.com/apple/swift-evolution/blob/master/proposals/0269-implicit-self-explicit-capture.md>
 [SE-0276]: <https://github.com/apple/swift-evolution/blob/master/proposals/0276-multi-pattern-catch-clauses.md>
 [SE-0280]: <https://github.com/apple/swift-evolution/blob/master/proposals/0280-enum-cases-as-protocol-witnesses.md>
+[SE-0287]: <https://github.com/apple/swift-evolution/blob/master/proposals/0287-implicit-member-chains.md>
 
 [SR-75]: <https://bugs.swift.org/browse/SR-75>
 [SR-106]: <https://bugs.swift.org/browse/SR-106>

CMakeLists.txt

@@ -914,7 +914,6 @@ if(NOT CMAKE_SYSTEM_NAME STREQUAL "Darwin")
   endif()
 endif()
 
-find_package(Python2 COMPONENTS Interpreter REQUIRED)
 find_package(Python3 COMPONENTS Interpreter REQUIRED)
 
 #

docs/ABI/Mangling.rst

@@ -176,6 +176,11 @@ Globals
   global ::= global 'MJ'                 // noncanonical specialized generic type metadata instantiation cache associated with global
   global ::= global 'MN'                 // noncanonical specialized generic type metadata for global
 
+  #if SWIFT_RUNTIME_VERSION >= 5.4
+    global ::= context (decl-name '_')+ 'WZ' // global variable one-time initialization function
+    global ::= context (decl-name '_')+ 'Wz' // global variable one-time initialization token
+  #endif
+
 A direct symbol resolves directly to the address of an object.  An
 indirect symbol resolves to the address of a pointer to the object.
 They are distinct manglings to make a certain class of bugs

docs/Branches.md

@@ -18,11 +18,11 @@ To switch from one set of branches to another, you can use `utils/update-checkou
 
 ## The Release Branches
 
-| Swift            | LLVM Project
-| ---------------- | ----------------------
-| swift-x.y-branch | swift/swift-x.y-branch
+| Swift       | LLVM Project
+| ----------- | -----------------
+| release/x.y | swift/release/x.y
 
-At some point before a release, a *release branch* will be created in every repository with a name like `swift-4.0-branch`. (The actual number is chosen by Apple.) After the branch has been created, commits must make it to this branch to make it into the release. In some cases, the [release manager][] for the branch will decide to merge in all additional changes from `master`; otherwise, cherry-picking changes and making a new pull request is the way to go. If there are any "patch" releases (e.g. Swift 4.0.1), they will also come from this branch.
+At some point before a release, a *release branch* will be created in every repository with a name like `release/5.3`. (The actual number is chosen by Apple.) After the branch has been created, commits must make it to this branch to make it into the release. In some cases, the [release manager][] for the branch will decide to merge in all additional changes from `master`; otherwise, cherry-picking changes and making a new pull request is the way to go. If there are any "patch" releases (e.g. Swift 5.3.1), they will also come from this branch.
 
 Note that these branches come not from the "development" branches (above), but the "upstream" branches (below). This is because they need to contain the latest changes not just from Swift, but from the LLVM project as well. For some releases, the release branch for the LLVM project will be timed to coincide with the corresponding llvm.org release branch.
 
@@ -35,7 +35,7 @@ Note that these branches come not from the "development" branches (above), but t
 
 `swift/master-next` is a branch for LLVM that includes all changes necessary to support Swift. Changes from llvm.org's master branch are automatically merged in. Why isn't this just `swift/master`? Well, because LLVM changes *very* rapidly, and that wouldn't be very stable. However, we do want to make sure the Swift stuff keeps working.
 
-If you are making changes to LLVM to support Swift, you'll probably need to work on them in `swift/master` to test them against Swift itself, but they should be committed to `swift/master-next`, and cherry-picked to the current release branch (`swift/swift-x.y-branch`) if needed. Remember, the release branches are automerged into `swift/master` on a regular basis.
+If you are making changes to LLVM to support Swift, you'll probably need to work on them in `swift/master` to test them against Swift itself, but they should be committed to `swift/master-next`, and cherry-picked to the current release branch (`swift/release/x.y`) if needed. Remember, the release branches are automerged into `swift/master` on a regular basis.
 
 (If you're making changes to LLVM Project that *aren't* about Swift, they should generally be made on llvm.org instead, then cherry-picked to the active release branch or `swift/master`.)
 
@@ -83,6 +83,6 @@ Some branches are *automerged* into other branches, to keep them in sync. This i
 - `master` is automerged into `master-next`
 
 ### LLVM Project
-- `swift/swift-x.y-branch` (the *latest* release branch) is automerged into `swift/master`
+- `swift/release/x.y` (the *latest* release branch) is automerged into `swift/master`
 - llvm.org's `master` is automerged into `swift/master-next`
-- llvm.org's release branch *may* be automerged into `swift/swift-x.y-branch`, if they are in sync
+- llvm.org's release branch *may* be automerged into `swift/release/x.y`, if they are in sync