Merge pull request #34477 from apple/tensorflow-merge

Merge 2020-10-28 into tensorflow

Author: texasmichelle

CHANGELOG.md

@@ -27,6 +27,20 @@ CHANGELOG
 Swift Next
 ----------
 
+* [SR-10069][]:
+
+  Function overloading now works in local contexts, making the following valid:
+
+  ```swift
+  func outer(x: Int, y: String) {
+    func doIt(_: Int) {}
+    func doIt(_: String) {}
+
+    doIt(x) // calls the first 'doIt(_:)' with an Int value
+    doIt(y) // calls the second 'doIt(_:)' with a String value
+  }
+  ```
+
 * [SE-0284][]:
 
   Functions, subscripts, and initializers may now have more than one variadic parameter, as long as all parameters which follow variadic parameters are labeled. This makes declarations like the following valid:
@@ -8196,6 +8210,7 @@ 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-10069]: <https://bugs.swift.org/browse/SR-10069>
 [SR-11298]: <https://bugs.swift.org/browse/SR-11298>
 [SR-11429]: <https://bugs.swift.org/browse/SR-11429>
 [SR-11700]: <https://bugs.swift.org/browse/SR-11700>

CMakeLists.txt

@@ -17,6 +17,11 @@ if(POLICY CMP0076)
   cmake_policy(SET CMP0076 NEW)
 endif()
 
+# Don't clobber existing variable values when evaluating `option()` declarations.
+if(POLICY CMP0077)
+  cmake_policy(SET CMP0077 NEW)
+endif()
+
 # Add path for custom CMake modules.
 list(APPEND CMAKE_MODULE_PATH
     "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules")

apinotes/os.apinotes

@@ -63,5 +63,5 @@ Functions:
   SwiftPrivate: true
   NullabilityOfRet: O
 - Name: _os_signpost_emit_with_name_impl
-  Availability: nonswift
-  AvailabilityMsg: 'Use os_signpost'
+  SwiftPrivate: true
+  NullabilityOfRet: O

cmake/modules/AddSwift.cmake

@@ -291,6 +291,16 @@ function(_add_host_variant_c_compile_flags target)
       target_compile_options(${target} PRIVATE -march=core2)
     endif()
   endif()
+
+  # The LLVM backend is built with these defines on most 32-bit platforms,
+  # llvm/llvm-project@66395c9, which can cause incompatibilities with the Swift
+  # frontend if not built the same way.
+  if("${SWIFT_HOST_VARIANT_ARCH}" MATCHES "armv6|armv7|i686" AND
+     NOT (SWIFT_HOST_VARIANT_SDK STREQUAL ANDROID AND SWIFT_ANDROID_API_LEVEL LESS 24))
+    target_compile_definitions(${target} PRIVATE
+      _LARGEFILE_SOURCE
+      _FILE_OFFSET_BITS=64)
+  endif()
 endfunction()
 
 function(_add_host_variant_link_flags target)
@@ -461,7 +471,7 @@ function(add_swift_host_library name)
       INSTALL_NAME_DIR "@rpath")
   elseif(SWIFT_HOST_VARIANT_SDK STREQUAL LINUX)
     set_target_properties(${name} PROPERTIES
-      INSTALL_RPATH "$ORIGIN:/usr/lib/swift/linux")
+      INSTALL_RPATH "$ORIGIN")
   elseif(SWIFT_HOST_VARIANT_SDK STREQUAL CYGWIN)
     set_target_properties(${name} PROPERTIES
       INSTALL_RPATH "$ORIGIN:/usr/lib/swift/cygwin")
@@ -630,3 +640,9 @@ macro(add_swift_tool_symlink name dest component)
   add_llvm_tool_symlink(${name} ${dest} ALWAYS_GENERATE)
   llvm_install_symlink(${name} ${dest} ALWAYS_GENERATE COMPONENT ${component})
 endmacro()
+
+# Declare that files in this library are built with LLVM's support
+# libraries available.
+macro(set_swift_llvm_is_available)
+  add_compile_options(-DSWIFT_LLVM_SUPPORT_IS_AVAILABLE)
+endmacro()

cmake/modules/AddSwiftUnittests.cmake

@@ -40,8 +40,13 @@ function(add_swift_unittest test_dirname)
   endif()
 
   if("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
+    # Add an @rpath to the swift library directory.
     set_target_properties(${test_dirname} PROPERTIES
       BUILD_RPATH ${SWIFT_LIBRARY_OUTPUT_INTDIR}/swift/macosx)
+    # Force all the swift libraries to be found via rpath.
+    add_custom_command(TARGET "${test_dirname}" POST_BUILD
+      COMMAND "${SWIFT_SOURCE_DIR}/utils/swift-rpathize.py"
+              "$<TARGET_FILE:${test_dirname}>")
   elseif("${SWIFT_HOST_VARIANT}" STREQUAL "android")
     swift_android_lib_for_arch(${SWIFT_HOST_VARIANT_ARCH} android_system_libs)
     set_property(TARGET "${test_dirname}" APPEND PROPERTY LINK_DIRECTORIES

cmake/modules/StandaloneOverlay.cmake

@@ -58,9 +58,17 @@ set(SWIFT_NATIVE_CLANG_TOOLS_PATH "${TOOLCHAIN_DIR}/usr/bin" CACHE STRING
 set(SWIFT_NATIVE_SWIFT_TOOLS_PATH "${TOOLCHAIN_DIR}/usr/bin" CACHE STRING
   "Path to Swift tools that are executable on the build machine.")
 
+# NOTE: The initialization in stdlib/CMakeLists.txt will be bypassed if we
+# directly invoke CMake for this directory, so we initialize the variables
+# related to library evolution here as well.
+
+option(SWIFT_STDLIB_STABLE_ABI
+  "Should stdlib be built with stable ABI (library evolution, resilience)."
+  TRUE)
+
 option(SWIFT_ENABLE_MODULE_INTERFACES
   "Generate .swiftinterface files alongside .swiftmodule files."
-  TRUE)
+  "${SWIFT_STDLIB_STABLE_ABI}")
 
 set(SWIFT_STDLIB_BUILD_TYPE "${CMAKE_BUILD_TYPE}" CACHE STRING
   "Build type for the Swift standard library and SDK overlays.")

docs/ABI/Mangling.rst

@@ -523,15 +523,20 @@ Types
   FUNCTION-KIND ::= 'U'                      // uncurried function type (currently not used)
   FUNCTION-KIND ::= 'K'                      // @auto_closure function type (noescape)
   FUNCTION-KIND ::= 'B'                      // objc block function type
-  FUNCTION-KIND ::= 'L'                      // objc block function type (escaping) (DWARF only; otherwise use 'B')
+  FUNCTION-KIND ::= 'zB' C-TYPE              // objc block type with non-canonical C type
+  FUNCTION-KIND ::= 'L'                      // objc block function type with canonical C type (escaping) (DWARF only; otherwise use 'B' or 'zB' C-TYPE)
   FUNCTION-KIND ::= 'C'                      // C function pointer type
+  FUNCTION-KIND ::= 'zC' C-TYPE              // C function pointer type with with non-canonical C type
   FUNCTION-KIND ::= 'A'                      // @auto_closure function type (escaping)
   FUNCTION-KIND ::= 'E'                      // function type (noescape)
   FUNCTION-KIND ::= 'F'                      // @differentiable function type
   FUNCTION-KIND ::= 'G'                      // @differentiable function type (escaping)
   FUNCTION-KIND ::= 'H'                      // @differentiable(linear) function type
   FUNCTION-KIND ::= 'I'                      // @differentiable(linear) function type (escaping)
 
+  C-TYPE is mangled according to the Itanium ABI, and prefixed with the length.
+  Non-ASCII identifiers are preserved as-is; we do not use Punycode.
+
   function-signature ::= params-type params-type async? throws? // results and parameters
 
   params-type ::= type 'z'? 'h'?              // tuple in case of multiple parameters or a single parameter with a single tuple type
@@ -600,7 +605,7 @@ mangled in to disambiguate.
   impl-function-type ::= type* 'I' FUNC-ATTRIBUTES '_'
   impl-function-type ::= type* generic-signature 'I' FUNC-ATTRIBUTES '_'
 
-  FUNC-ATTRIBUTES ::= PATTERN-SUBS? INVOCATION-SUBS? PSEUDO-GENERIC? CALLEE-ESCAPE? DIFFERENTIABILITY-KIND? CALLEE-CONVENTION FUNC-REPRESENTATION? COROUTINE-KIND? (PARAM-CONVENTION PARAM-DIFFERENTIABILITY?)* RESULT-CONVENTION* ('Y' PARAM-CONVENTION)* ('z' RESULT-CONVENTION RESULT-DIFFERENTIABILITY?)?
+  FUNC-ATTRIBUTES ::= PATTERN-SUBS? INVOCATION-SUBS? PSEUDO-GENERIC? CALLEE-ESCAPE? DIFFERENTIABILITY-KIND? CALLEE-CONVENTION FUNC-REPRESENTATION? COROUTINE-KIND? ASYNC? (PARAM-CONVENTION PARAM-DIFFERENTIABILITY?)* RESULT-CONVENTION* ('Y' PARAM-CONVENTION)* ('z' RESULT-CONVENTION RESULT-DIFFERENTIABILITY?)?
 
   PATTERN-SUBS ::= 's'                       // has pattern substitutions
   INVOCATION-SUB ::= 'I'                     // has invocation substitutions
@@ -618,7 +623,9 @@ mangled in to disambiguate.
   CALLEE-CONVENTION ::= 't'                  // thin
 
   FUNC-REPRESENTATION ::= 'B'                // C block invocation function
+  FUNC-REPRESENTATION ::= 'zB' C-TYPE        // C block invocation function with non-canonical C type
   FUNC-REPRESENTATION ::= 'C'                // C global function
+  FUNC-REPRESENTATION ::= 'zC' C-TYPE        // C global function with non-canonical C type
   FUNC-REPRESENTATION ::= 'M'                // Swift method
   FUNC-REPRESENTATION ::= 'J'                // ObjC method
   FUNC-REPRESENTATION ::= 'K'                // closure
@@ -627,6 +634,8 @@ mangled in to disambiguate.
   COROUTINE-KIND ::= 'A'                     // yield-once coroutine
   COROUTINE-KIND ::= 'G'                     // yield-many coroutine
 
+  ASYNC ::= 'H'                              // @async
+
   PARAM-CONVENTION ::= 'i'                   // indirect in
   PARAM-CONVENTION ::= 'c'                   // indirect in constant
   PARAM-CONVENTION ::= 'l'                   // indirect inout
@@ -993,6 +1002,7 @@ Function Specializations
 ::
 
   specialization ::= type '_' type* 'Tg' SPEC-INFO     // Generic re-abstracted specialization
+  specialization ::= type '_' type* 'Ts' SPEC-INFO     // Generic re-abstracted prespecialization
   specialization ::= type '_' type* 'TG' SPEC-INFO     // Generic not re-abstracted specialization
   specialization ::= type '_' type* 'Ti' SPEC-INFO     // Inlined function with generic substitutions.
 

docs/CompilerPerformance.md

@@ -815,8 +815,8 @@ are helpful in such cases:
 
   - `llvm-bcanalyzer` can print (in rough form) the contents of LLVM bitcode
     streams, such as Swift module files and the PCH/PCM files clang stores its
-    serialized ASTs in. The latter requires combing `llvm-objdump` and
-    `llvm-bcanalyzer` in the following fashion: `llvm-objdump -raw-clang-ast
+    serialized ASTs in. The latter requires combining `llvm-objdump` and
+    `llvm-bcanalyzer` in the following fashion: `llvm-objdump --raw-clang-ast
     file.pcm | llvm-bcanalyzer -dump`
 
   - `llvm-dwarfdump` and `llvm-dis` can be used to print textual representations

docs/CppInteroperabilityManifesto.md

@@ -307,7 +307,7 @@ provide the following guarantees:
 
 - `inout` are backed by initialized memory on function entry and function exit
   (an implication of the copy-in/copy-out semantics). Destroying the object in
-  `inout` requires using unsafe construts. Therefore, in safe Swift `inout`
+  `inout` requires using unsafe constructs. Therefore, in safe Swift `inout`
   parameters are backed by initialized memory throughout function execution.
 
 - `inout` parameters don't alias each other or any other values that program is
@@ -1033,7 +1033,7 @@ in all Swift code, but it is feasible for local variables of concrete types.
 An example where it is not possible to maintain precise destruction semantics
 for C++ classes is in a generic Swift function that is called with a C++ class
 as a type parameter. In this case, we must be able to compile one definition of
-a Swift function, which must work regradless of the nature of the type (be it a
+a Swift function, which must work regardless of the nature of the type (be it a
 Swift type or a C++ class). This limitation does not seem too bad, because RAII
 types are not often passed as type parameters to templates in C++, which creates
 a reason to believe it will not be common in Swift either.
@@ -3197,7 +3197,7 @@ UTF-8 data.
 class Employee {
 public:
   std::string DebugDescription() const;
-  [[swift::import_as_std_string]] std::string SeriaziledAsProtobuf() const;
+  [[swift::import_as_std_string]] std::string SerializedAsProtobuf() const;
 };
 ```
 

docs/DebuggingTheCompiler.md

@@ -30,6 +30,8 @@ benefit of all Swift developers.
         - [Debugging the Compiler using advanced LLDB Breakpoints](#debugging-the-compiler-using-advanced-lldb-breakpoints)
         - [Debugging the Compiler using LLDB Scripts](#debugging-the-compiler-using-lldb-scripts)
         - [Custom LLDB Commands](#custom-lldb-commands)
+    - [Debugging at LLVM Level](#debugging-at-llvm-level)
+        - [Options for Dumping LLVM IR](#options-for-dumping-llvm-ir)
     - [Bisecting Compiler Errors](#bisecting-compiler-errors)
         - [Bisecting on SIL optimizer pass counts to identify optimizer bugs](#bisecting-on-sil-optimizer-pass-counts-to-identify-optimizer-bugs)
         - [Using git-bisect in the presence of branch forwarding/feature branches](#using-git-bisect-in-the-presence-of-branch-forwardingfeature-branches)
@@ -537,6 +539,20 @@ to define custom commands using just other lldb commands. For example,
 
     (lldb) command alias cs sequence p/x $rax; stepi
 
+## Debugging at LLVM Level
+
+### Options for Dumping LLVM IR
+
+Similar to SIL, one can configure LLVM to dump the llvm-ir at various points in
+the pipeline. Here is a quick summary of the various options:
+
+* ``-Xllvm -print-before=$PASS_ID``: Print the LLVM IR before a specified LLVM pass runs.
+* ``-Xllvm -print-before-all``: Print the LLVM IR before each pass runs.
+* ``-Xllvm -print-after-all``: Print the LLVM IR after each pass runs.
+* ``-Xllvm -filter-print-funcs=$FUNC_NAME_1,$FUNC_NAME_2,...,$FUNC_NAME_N``:
+  When printing IR for functions for print-[before|after]-all options, Only
+  print the IR for functions whose name is in this comma separated list.
+
 ## Bisecting Compiler Errors
 
 ### Bisecting on SIL optimizer pass counts to identify optimizer bugs

docs/DevelopmentTips.md

@@ -33,9 +33,11 @@ Compilation times for the compiler and the standard library can be agonizing, es
 ```
 $ brew install sccache
 $ sccache --start-server
-$ ./swift/utils/build-script MY_ARGS --cmake-c-launcher $(which sccache) --cmake-cxx-launcher $(which sccache)
+$ ./swift/utils/build-script MY_ARGS --sccache
 ```
 
+If you want to always use sccache, you can `export SWIFT_USE_SCCACHE=1` and the build script will pick it up.
+
 Given the size of artifacts generated, you might also want to bump the cache size from the default 10GB to something larger, say by putting `export SCCACHE_CACHE_SIZE="50G"` in your dotfile(s).
 
 You can run some compiles to see if it is actually doing something by running `sccache --show-stats`. Depending on the exact compilation task you're running, you might see very different cache hit rates. For example, `sccache` is particularly effective if you're rebuilding LLVM, which doesn't change so frequently from the Swift compiler's perspective. On the other hand, if you're changing the compiler's AST, the cache hit rate is likely to be much lower.

docs/Diagnostics.md

@@ -100,7 +100,7 @@ Educational notes should:
 - Explain a single language concept. This makes them easy to reuse across related diagnostics and helps keep them clear, concise, and easy to understand.
 - Be written in unabbreviated English. These are longer-form messages compared to the main diagnostic, so there's no need to omit needless words and punctuation.
 - Not generally exceed 3-4 paragraphs. Educational notes should be clear and easily digestible. Messages which are too long also have the potential to create UX issues on the command line.
-- Be accessible. Educational notes should be beginner friendly and avoid assuming unnecesary prior knowledge. The goal is not only to help users understand what a diagnostic is telling them, but also to turn errors and warnings into "teachable moments".
+- Be accessible. Educational notes should be beginner friendly and avoid assuming unnecessary prior knowledge. The goal is not only to help users understand what a diagnostic is telling them, but also to turn errors and warnings into "teachable moments".
 - Include references to relevant chapters of _The Swift Programming Language_.
 - Be written in Markdown, but avoid excessive markup which negatively impacts the terminal UX.
 

docs/DifferentiableProgramming.md

@@ -2542,7 +2542,7 @@ As defined above, the `@differentiable` function type attributes requires all
 non-`@noDerivative` arguments and results to conform to the `@differentiable`
 attribute. However, there is one exception: when the type of an argument or
 result is a function type, e.g. `@differentiable (T) -> @differentiable (U) ->
-V`. This is because we need to differentiate higher-order funtions.
+V`. This is because we need to differentiate higher-order functions.
 
 Mathematically, the differentiability of `@differentiable (T, U) -> V` is
 similar to that of `@differentiable (T) -> @differentiable (U) -> V` in that

docs/Driver.md

@@ -205,7 +205,7 @@ in becoming more like non-whole-module builds.
 
 ## Incremental Builds ##
 
-Incremental builds in Swift work by primarily by cross-file dependency
+Incremental builds in Swift work primarily by cross-file dependency
 analysis, described in [DependencyAnalysis.md](DependencyAnalysis.md).
 Compiling a single file might be necessary because that file has changed, but
 it could also be because that file depends on something else that might have

docs/ExternalResources.md

@@ -135,11 +135,24 @@ https://medium.com/kinandcartacreated/contributing-to-swift-part-2-efebcf7b6c93
 
 ## Code generation, runtime and ABI
 
-- The Swift Runtime ([Part 1: Heap Objects][], [Part 2: Type Layout][])
-  by Jordan Rose (blog post series, Aug-Sep 2020): This blog post series
-  describes the runtime layout for classes, closures and structs, as well
-  as basic runtime functionality such as retain/release that needs to be
-  handled when porting Swift to a new platform, such as [Mac OS 9][].
+- [The Swift Runtime][] by Jordan Rose (blog post series, Aug-Oct 2020):
+  This blog post series describes the runtime layout for different structures,
+  runtime handling for metadata, as well as basic runtime functionality such
+  as retain/release that needs to be handled when porting Swift to a new
+  platform, such as [Mac OS 9][].
+  - [Part 1: Heap Objects][]
+  - [Part 2: Type Layout][]
+  - [Part 3: Type Metadata][]
+  - [Part 4: Uniquing Caches][]
+  - [Part 5: Class Metadata][]
+  - [Part 6: Class Metadata Initialization][]
+  - [Part 7: Enums][]
+- [Implementing the Swift Runtime in Swift][]
+  by JP Simard and Jesse Squires with Jordan Rose (podcast episode, Oct 2020):
+  This episode describes Jordan's effort to port Swift to Mac OS 9.
+  It touches on a wide variety of topics, such as ObjC interop, memory layout
+  guarantees, performance, library evolution, writing low-level code in Swift,
+  the workflow of porting Swift to a new platform and the design of Swift.
 - [How Swift Achieved Dynamic Linking Where Rust Couldn't][] by Alexis
   Beingessner (blog post, Nov 2019): This blog post describes Swift's approach
   for compiling polymorphic functions, contrasting it with the strategy used by
@@ -174,9 +187,16 @@ https://medium.com/kinandcartacreated/contributing-to-swift-part-2-efebcf7b6c93
   value witness tables, type metadata, abstraction patterns, reabstraction,
   reabstraction thunks and protocol witness tables.
 
+[Mac OS 9]: https://belkadan.com/blog/2020/04/Swift-on-Mac-OS-9/
+[The Swift Runtime]: https://belkadan.com/blog/tags/swift-runtime/
 [Part 1: Heap Objects]: https://belkadan.com/blog/2020/08/Swift-Runtime-Heap-Objects/
 [Part 2: Type Layout]: https://belkadan.com/blog/2020/09/Swift-Runtime-Type-Layout/
-[Mac OS 9]: https://belkadan.com/blog/2020/04/Swift-on-Mac-OS-9/
+[Part 3: Type Metadata]: https://belkadan.com/blog/2020/09/Swift-Runtime-Type-Metadata/
+[Part 4: Uniquing Caches]: https://belkadan.com/blog/2020/09/Swift-Runtime-Uniquing-Caches/
+[Part 5: Class Metadata]: https://belkadan.com/blog/2020/09/Swift-Runtime-Class-Metadata/
+[Part 6: Class Metadata Initialization]: https://belkadan.com/blog/2020/10/Swift-Runtime-Class-Metadata-Initialization/
+[Part 7: Enums]: https://belkadan.com/blog/2020/10/Swift-Runtime-Enums/
+[Implementing the Swift Runtime in Swift]: https://spec.fm/podcasts/swift-unwrapped/1DMLbJg5
 [How Swift Achieved Dynamic Linking Where Rust Couldn't]: https://gankra.github.io/blah/swift-abi/
 [arm64e: An ABI for Pointer Authentication]: https://youtu.be/C1nZvpEBfYA
 [Exploiting The Swift ABI]: https://youtu.be/0rHG_Pa86oA

docs/HowToGuides/FAQ.md

@@ -42,7 +42,7 @@ built compiler to compile both packages and Xcode projects.
    Create a build setting `SWIFT_EXEC` with the value set to `/path/to/swiftc`.
    If you now do a clean build, your locally built compiler will be used.
 
-   At the time of writing, in the latest Xcode 12 beta, `SWIFT_EXEC` does not
+   At the time of writing, in the latest Xcode 12.2 beta 3, `SWIFT_EXEC` does not
    work for SwiftPM integration inside Xcode, so this will not work for Xcode
    projects that depend on SwiftPM packages.