Resolving conlficts

Author: LucianoPAlmeida

.gitattributes

@@ -0,0 +1,2 @@
+*.swift.gyb linguist-language=Swift
+*.cpp.gyb linguist-language=C++

CHANGELOG.md

@@ -4,27 +4,27 @@ CHANGELOG
 <details>
 <summary>Note: This is in reverse chronological order, so newer entries are added to the top.</summary>
 
-| Contents               |
-| :--------------------- |
-| [Swift Next](#swift-next) |
-| [Swift 5.1](#swift-51) |
-| [Swift 5.0](#swift-50) |
-| [Swift 4.2](#swift-42) |
-| [Swift 4.1](#swift-41) |
-| [Swift 4.0](#swift-40) |
-| [Swift 3.1](#swift-31) |
-| [Swift 3.0](#swift-30) |
-| [Swift 2.2](#swift-22) |
-| [Swift 2.1](#swift-21) |
-| [Swift 2.0](#swift-20) |
-| [Swift 1.2](#swift-12) |
-| [Swift 1.1](#swift-11) |
-| [Swift 1.0](#swift-10) |
+| Version                | Released   | Toolchain   |
+| :--------------------- | :--------- | :---------- |
+| [Swift 5.2](#swift-52) |            |             |
+| [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
-----------
+Swift 5.2
+---------
 
 * [SR-11429][]:
 
@@ -58,63 +58,6 @@ Swift Next
   (foo as Magic)(5)
   ```
 
-* [SR-11298][]:
-
-  A class-constrained protocol extension, where the extended protocol does
-  not impose a class constraint, will now infer the constraint implicitly.
-
-  ```swift
-  protocol Foo {}
-  class Bar: Foo {
-    var someProperty: Int = 0
-  }
-
-  // Even though 'Foo' does not impose a class constraint, it is automatically
-  // inferred due to the Self: Bar constraint.
-  extension Foo where Self: Bar {
-    var anotherProperty: Int {
-      get { return someProperty }
-      // As a result, the setter is now implicitly nonmutating, just like it would
-      // be if 'Foo' had a class constraint.
-      set { someProperty = newValue }
-    }
-  }
-  ```
-  
-  As a result, this could lead to code that currently compiles today to throw an error.
-  
-  ```swift
-  protocol Foo {
-    var someProperty: Int { get set }
-  }
-  
-  class Bar: Foo {
-    var someProperty = 0
-  }
-  
-  extension Foo where Self: Bar {
-    var anotherProperty1: Int {
-      get { return someProperty }
-      // This will now error, because the protocol requirement
-      // is implicitly mutating and the setter is implicitly 
-      // nonmutating.
-      set { someProperty = newValue } // Error
-    }
-  }
-  ```
-
-  **Workaround**: Define a new mutable variable inside the setter that has a reference to `self`:
-  
-  ```swift
-  var anotherProperty1: Int {
-    get { return someProperty }
-    set {
-      var mutableSelf = self
-      mutableSelf.someProperty = newValue // Okay
-    }
-  }
-  ```
-
 * [SE-0253][]:
 
   Values of types that declare `func callAsFunction` methods can be called
@@ -140,7 +83,7 @@ Swift Next
 
 * [SR-4206][]:
 
-  A method override is no longer allowed to have a generic signature with
+  A method override is no longer allowed to have a generic signature with 
   requirements not imposed by the base method. For example:
 
   ```
@@ -7856,5 +7799,4 @@ Swift 1.0
 [SR-8974]: <https://bugs.swift.org/browse/SR-8974>
 [SR-9043]: <https://bugs.swift.org/browse/SR-9043>
 [SR-9827]: <https://bugs.swift.org/browse/SR-9827>
-[SR-11298]: <https://bugs.swift.org/browse/SR-11298>
 [SR-11429]: <https://bugs.swift.org/browse/SR-11429>

CMakeLists.txt

@@ -11,6 +11,8 @@ endif()
 list(APPEND CMAKE_MODULE_PATH
     "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules")
 
+set(CMAKE_DISABLE_IN_SOURCE_BUILD YES)
+
 if(DEFINED CMAKE_JOB_POOLS)
   # CMake < 3.11 doesn't support CMAKE_JOB_POOLS. Manually set the property.
   set_property(GLOBAL PROPERTY JOB_POOLS "${CMAKE_JOB_POOLS}")
@@ -125,7 +127,7 @@ set(SWIFT_ANALYZE_CODE_COVERAGE FALSE CACHE STRING
 # SWIFT_VERSION is deliberately /not/ cached so that an existing build directory
 # can be reused when a new version of Swift comes out (assuming the user hasn't
 # manually set it as part of their own CMake configuration).
-set(SWIFT_VERSION "5.1")
+set(SWIFT_VERSION "5.1.1")
 
 set(SWIFT_VENDOR "" CACHE STRING
     "The vendor name of the Swift compiler")

README.md

@@ -6,7 +6,6 @@
 | | **Architecture** | **Master** | **Package** |
 |---|:---:|:---:|:---:|
 | **macOS**        | x86_64 |[![Build Status](https://ci.swift.org/job/oss-swift-incremental-RA-osx/lastCompletedBuild/badge/icon)](https://ci.swift.org/job/oss-swift-incremental-RA-osx)|[![Build Status](https://ci.swift.org/job/oss-swift-package-osx/lastCompletedBuild/badge/icon)](https://ci.swift.org/job/oss-swift-package-osx)|
-| **Ubuntu 14.04** | x86_64 | [![Build Status](https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/lastCompletedBuild/badge/icon)](https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04)|[![Build Status](https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/lastCompletedBuild/badge/icon)](https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04)|
 | **Ubuntu 16.04** | x86_64 | [![Build Status](https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/lastCompletedBuild/badge/icon)](https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04)|[![Build Status](https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_04/lastCompletedBuild/badge/icon)](https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_04)|
 | **Ubuntu 18.04** | x86_64 | [![Build Status](https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-18_04/lastCompletedBuild/badge/icon)](https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-18_04)|[![Build Status](https://ci.swift.org/job/oss-swift-package-linux-ubuntu-18_04/lastCompletedBuild/badge/icon)](https://ci.swift.org/job/oss-swift-package-linux-ubuntu-18_04)|
 

cmake/modules/CMakeLists.txt

@@ -16,4 +16,4 @@ set(SWIFT_LIBRARY_DIRS ${SWIFT_LIBRARY_OUTPUT_INTDIR})
 configure_file(
   SwiftConfig.cmake.in
   ${swift_cmake_builddir}/SwiftConfig.cmake
-  @ONLY)
+  @ONLY)

cmake/modules/SwiftConfig.cmake.in

@@ -6,13 +6,13 @@ set(SWIFT_VERSION @SWIFT_VERSION@)
 set(SWIFT_MAIN_SRC_DIR @SWIFT_SOURCE_DIR@)
 
 set(SWIFT_INCLUDE_DIRS "@SWIFT_INCLUDE_DIRS@")
-set(SWIFT_LIBRARY_DIRS "@SWIFT_CONFIG_LIBRARY_DIRS@")
+set(SWIFT_LIBRARY_DIRS "@SWIFT_LIBRARY_DIRS@")
 
 # These variables are duplicated, but they must match the LLVM variables of the
 # same name. The variables ending in "S" could some day become lists, and are
 # preserved for convention and compatibility.
 set(SWIFT_INCLUDE_DIR "@SWIFT_INCLUDE_DIRS@")
-set(SWIFT_LIBRARY_DIR "@SWIFT_CONFIG_LIBRARY_DIRS@")
+set(SWIFT_LIBRARY_DIR "@SWIFT_LIBRARY_DIRS@")
 
 set(SWIFT_CMAKE_DIR "@SWIFT_CMAKE_DIR@")
 set(SWIFT_BINARY_DIR "@SWIFT_BINARY_DIR@")

cmake/modules/SwiftSource.cmake

@@ -310,12 +310,12 @@ function(_compile_swift_files
     set(module_base "${module_dir}/${SWIFTFILE_MODULE_NAME}")
     if(SWIFTFILE_SDK IN_LIST SWIFT_APPLE_PLATFORMS)
       set(specific_module_dir "${module_base}.swiftmodule")
-      set(specific_module_private_dir "${specific_module_dir}/Private")
-      set(source_info_file "${specific_module_private_dir}/${SWIFTFILE_ARCHITECTURE}.swiftsourceinfo")
+      set(specific_module_project_dir "${specific_module_dir}/Project")
+      set(source_info_file "${specific_module_project_dir}/${SWIFTFILE_ARCHITECTURE}.swiftsourceinfo")
       set(module_base "${module_base}.swiftmodule/${SWIFTFILE_ARCHITECTURE}")
     else()
       set(specific_module_dir)
-      set(specific_module_private_dir)
+      set(specific_module_project_dir)
       set(source_info_file "${module_base}.swiftsourceinfo")
     endif()
     set(module_file "${module_base}.swiftmodule")
@@ -354,7 +354,7 @@ function(_compile_swift_files
                                DESTINATION "lib${LLVM_LIBDIR_SUFFIX}/swift/${library_subdir}"
                                COMPONENT "${SWIFTFILE_INSTALL_IN_COMPONENT}"
                                OPTIONAL
-                               PATTERN "Private" EXCLUDE)
+                               PATTERN "Project" EXCLUDE)
   else()
     swift_install_in_component(FILES ${module_outputs}
                                DESTINATION "lib${LLVM_LIBDIR_SUFFIX}/swift/${library_subdir}"
@@ -495,7 +495,7 @@ function(_compile_swift_files
         COMMAND
           "${CMAKE_COMMAND}" "-E" "make_directory" ${module_dir}
           ${specific_module_dir}
-          ${specific_module_private_dir}
+          ${specific_module_project_dir}
         COMMAND
           "${PYTHON_EXECUTABLE}" "${line_directive_tool}" "@${file_path}" --
           "${swift_compiler_tool}" "-emit-module" "-o" "${module_file}"

docs/CToSwiftNameTranslation.md

@@ -212,6 +212,29 @@ Additionally, typedefs for `void *` or `const void *` that are themselves annota
 If a typedef's underlying type is itself a "CF pointer" typedef, the "alias" typedef will be imported as a regular typealias, with the suffix "Ref" still dropped from its name (if present) unless doing so would conflict with another declaration in the same module as the typedef.
 
 
+## Objective-C Properties
+
+By default, most property names are not transformed at all. However, if the getter of a property overrides a superclass or adopted protocol method that is also a property accessor, the Swift name of the overridden accessor's property will be used for consistency. If there's more than one such name, one is chosen arbitrarily.
+
+Properties with the type `BOOL` or `Boolean` use the name of the getter as the name of the Swift property by default, rather than the name of the property in Objective-C. This accounts for a difference in Swift and Objective-C naming conventions for boolean properties that use "is".
+
+```objc
+@property(getter=isContrivedExample) BOOL contrivedExample;
+@property BOOL hasAnotherForm;
+```
+
+```swift
+var isContrivedExample: Bool { get set }
+var hasAnotherForm: Bool { get set }
+```
+
+_This rule should probably have applied to C's native `bool` as well._
+
+A property declaration with the `SwiftImportPropertyAsAccessors` API note will not be imported at all, and its accessors will be imported as methods. Additionally, properties whose names start with "accessibility" in the NSAccessibility protocol are always imported as methods, as are properties whose names start with "accessibility" in an `@interface` declaration (class or category) that provides the adoption of NSAccessibility.
+
+_Objective-C code has historically not been consistent about whether the NSAccessibility declarations should be considered properties and therefore the Swift compiler chooses to import them as methods, as a sort of lowest common denominator._
+
+
 ## `swift_private`
 
 The `swift_private` Clang attribute prepends `__` onto the base name of any declaration being imported except initializers. For initializers with no arguments, a dummy `Void` argument with the name `__` is inserted; otherwise, the label for the first argument has `__` prepended. This transformation takes place after any other name manipulation, unless the declaration has a custom name. It will not occur if the declaration is an override; in that case the name needs to match the overridden declaration.
@@ -252,6 +275,8 @@ __attribute__((swift_name("SpacecraftCoordinates")))
 struct SPKSpacecraftCoordinates {
   double x, y, z, t; // space and time, of course
 };
+
+// Usually seen as NS_SWIFT_NAME.
 ```
 
 ```swift
@@ -287,12 +312,10 @@ The `swift_name` attribute can be used to give a C function a custom name. The v
 ```objc
 __attribute__((swift_name("doSomething(to:bar:)")))
 void doSomethingToFoo(Foo *foo, int bar);
-
-// Usually seen as NS_SWIFT_NAME.
 ```
 
 ```swift
-func doSomething(foo: UnsafeMutablePointer<Foo>, bar: Int32)
+func doSomething(to foo: UnsafeMutablePointer<Foo>, bar: Int32)
 ```
 
 An underscore can be used in place of an empty parameter label, as in Swift.
@@ -430,4 +453,86 @@ Although enumerators always have global scope in C, they are often imported as m
 
 _Currently, `swift_name` does not even allow importing an enum case as a member of the enum type itself, even if the enum is not recognized as an `@objc` enum, error code enum, or option set (i.e. the situation where a case is imported as a global constant)._
 
+
+### Fields of structs and unions; Objective-C properties
+
+The `swift_name` attribute can be applied to rename a struct or union field or an Objective-C property (whether on a class or a protocol). The value of the attribute must be a valid Swift identifier.
+
+```objc
+struct SPKSpaceflightBooking {
+  const SPKLocation * _Nullable destination;
+  bool roundTrip __attribute__((swift_name("isRoundTrip")));
+};
+```
+
+```swift
+struct SPKSpaceflightBooking {
+  var destination: UnsafePointer<SPKLocation>?
+  var isRoundTrip: Bool
+}
+```
+
+
+### Objective-C methods
+
+The `swift_name` attribute can be used to give an Objective-C method a custom name. The value of the attribute must be a full Swift function name, including parameter labels.
+
+```objc
+- (void)doSomethingToFoo:(Foo *)foo bar:(int)bar
+  __attribute__((swift_name("doSomethingImportant(to:bar:)")));
+```
+
+```swift
+func doSomethingImportant(to foo: UnsafeMutablePointer<Foo>, bar: Int32)
+```
+
+As with functions, an underscore can be used to represent an empty parameter label.
+
+Methods that follow the NSError out-parameter convention may provide one fewer parameter label than the number of parameters in the original method to indicate that a parameter should be dropped, but they do not have to. The `swift_error` attribute is still respected even when using a custom name for purposes of transforming an NSError out-parameter and the method return type.
+
+```objc
+- (BOOL)doSomethingRiskyAndReturnError:(NSError **)error
+  __attribute__((swift_name("doSomethingRisky()")));
+- (BOOL)doSomethingContrived:(NSString *)action error:(NSError **)outError
+  __attribute__((swift_name("doSomethingContrived(_:error:)")));
+```
+
+```swift
+func doSomethingRisky() throws
+func doSomethingContrived(_ action: String, error: ()) throws
+```
+
+A base name of "init" can be used on a *class* method that returns `instancetype` or the containing static type in order to import that method as an initializer. Any other custom name *prevents* a class method from being imported as an initializer even if it would normally be inferred as one.
+
+```objc
++ (Action *)makeActionWithHandler:(void(^)(void))handler
+  __attribute__((swift_name("init(handler:)")));
++ (instancetype)makeActionWithName:(NSString *)name
+  __attribute__((swift_name("init(name:)")));
+```
+
+```swift
+/* non-inherited */ init(handler: () -> Void)
+init(name: String)
+```
+
+A no-argument method imported as an initializer can be given a dummy argument label to disambiguate it from the no-argument `init()`, whether the method is an init-family instance method or a factory class method in Objective-C.
+
+```objc
+- (instancetype)initSafely
+  __attribute__((swift_name("init(safe:)")));
++ (instancetype)makeDefaultAction
+  __attribute__((swift_name("init(default:)")));
+```
+
+```swift
+init(safe: ())
+init(default: ())
+```
+
+A custom name on an instance method with one of Objective-C's subscript selectors (`objectAtIndexedSubscript:`, `objectForKeyedSubscript:`, `setObject:atIndexedSubscript:`, or `setObject:forKeyedSubscript:`) prevents that method from being imported as a subscript or used as the accessor for another subscript.
+
+_Currently, this only works if *both* methods in a read/write subscript are given custom names; if just one is, a read/write subscript will still be formed. A read-only subscript only has one method to rename._
+
+
 ## More to come...

docs/Diagnostics.md

@@ -104,3 +104,19 @@ Most diagnostics have no reason to change behavior under editor mode. An example
 - `%error` - Represents a branch in a `%select` that should never be taken. In debug builds of the compiler this produces an assertion failure.
 
 - `%%` - Emits a literal percent sign.
+
+### Diagnostic Verifier ###
+
+(This section is specific to the Swift compiler's diagnostic engine.)
+
+If the `-verify` frontend flag is used, the Swift compiler will check emitted diagnostics against specially formatted comments in the source. This feature is used extensively throughout the test suite to ensure diagnostics are emitted with the correct message and source location.
+
+An expected diagnostic is denoted by a comment which begins with `expected-error`, `expected-warning`, `expected-note`, or `expected-remark`. It is followed by:
+
+- (Optional) Location information. By default, the comment will match any diagnostic emitted on the same line. However, it's possible to override this behavior and/or specify column information as well. `// expected-error@-1 ...` looks for an error on the previous line, `// expected-warning@+1:3 ...` looks for a warning on the next line at the third column, and `// expected-note@:7 ...` looks for a note on the same line at the seventh column.
+
+- (Optional) A match count which specifies how many times the diagnostic is expected to appear. This may be a positive integer or `*`, which allows for zero or more matches. The match count must be surrounded by whitespace if present. For example, `// expected-error 2 ...` looks for two matching errors, and `// expected-warning * ...` looks for any number of matching warnings.
+
+- (Required) The expected error message. The message should be enclosed in double curly braces and should not include the `error:`/`warning:`/`note:`/`remark:` prefix. For example, `// expected-error {{invalid redeclaration of 'y'}}` would match an error with that message on the same line. The expected message does not need to match the emitted message verbatim. As long as the expected message is a substring of the original message, they will match.
+
+- (Optional) Expected fix-its. These are each enclosed in double curly braces and appear after the expected message. An expected fix-it consists of a column range followed by the text it's expected to be replaced with. For example, `let r : Int i = j // expected-error{{consecutive statements}} {{12-12=;}}` will match a fix-it attached to the consecutive statements error which inserts a semicolon at column 12, just after the 't' in 'Int'. The special {{none}} specifier is also supported, which will cause the diagnostic match to fail if unexpected fix-its are produced.

docs/Testing.md

@@ -232,7 +232,7 @@ code for the target that is not the build machine:
 
 * ``%target-typecheck-verify-swift``: parse and type check the current Swift file
   for the target platform and verify diagnostics, like ``swift -frontend -typecheck -verify
-  %s``.
+  %s``. For further explanation of `-verify` mode, see [Diagnostics.md](Diagnostics.md).
 
   Use this substitution for testing semantic analysis in the compiler.
 

docs/WindowsBuild.md

@@ -186,13 +186,11 @@ cmake -G "Visual Studio 2017" -A x64 -T "host=x64"^ ...
 md "S:\b\lldb"
 cd "S:\b\lldb"
 cmake -G Ninja^
+  -DLLVM_DIR="S:/b/llvm/lib/cmake/llvm"^
+  -DClang_DIR="S:/b/llvm/lib/cmake/clang"^
+  -DSwift_DIR="S:/b/swift/lib/cmake/swift"^
   -DCMAKE_BUILD_TYPE=RelWithDebInfo^
   -DLLDB_ALLOW_STATIC_BINDINGS=YES^
-  -DLLDB_PATH_TO_CLANG_SOURCE="S:\clang"^
-  -DLLDB_PATH_TO_SWIFT_SOURCE="S:\swift"^
-  -DLLDB_PATH_TO_CLANG_BUILD="S:\b\llvm"^
-  -DLLDB_PATH_TO_LLVM_BUILD="S:\b\llvm"^
-  -DLLDB_PATH_TO_SWIFT_BUILD="S:\b\swift"^
   -DLLVM_ENABLE_ASSERTIONS=ON^
   -DPYTHON_HOME="%ProgramFiles(x86)%\Microsoft Visual Studio\Shared\Python37_64"^
   S:\lldb