---

yaml
---
r: 270303
b: refs/heads/tensorflow-merge
c: b29f1ee
h: refs/heads/master
i:
  270301: 223576a
  270299: 44a61a8
  270295: 8057901
  270287: 06d29ed
  270271: bf8c1c3

Author: Harlan Haskins

[refs]

@@ -1128,4 +1128,4 @@ refs/tags/swift-4.2.1-RELEASE: 02a6ca969ea1387475b6caeb69c31186df7d30b6
 refs/tags/swift-DEVELOPMENT-SNAPSHOT-2018-11-01-a: 3b0299288f8287094b9ef587f46df54f42a347af
 refs/heads/5.0-add-libcxx-and-clang-tools-extra: eb6e6f9b0a551e7804e96d0dac83add11ec73977
 refs/heads/Fix-DataCreateSmall: e15aff31b7406a5b2dadac9d7810941cec85035a
-refs/heads/tensorflow-merge: 121f15b2ac2968f8fb212d63d8562c1d85e277b3
+refs/heads/tensorflow-merge: b29f1ee1a26b6fe1d68bece094d3f962d44b4370

branches/tensorflow-merge/cmake/modules/SwiftSharedCMakeConfig.cmake

@@ -7,6 +7,8 @@ macro(swift_common_standalone_build_config_llvm product is_cross_compiling)
   precondition_translate_flag(${product}_PATH_TO_LLVM_SOURCE PATH_TO_LLVM_SOURCE)
   precondition_translate_flag(${product}_PATH_TO_LLVM_BUILD PATH_TO_LLVM_BUILD)
 
+  file(TO_CMAKE_PATH "${PATH_TO_LLVM_BUILD}" PATH_TO_LLVM_BUILD)
+
   set(SWIFT_LLVM_CMAKE_PATHS
       "${PATH_TO_LLVM_BUILD}/share/llvm/cmake"
       "${PATH_TO_LLVM_BUILD}/lib/cmake/llvm")
@@ -139,6 +141,9 @@ macro(swift_common_standalone_build_config_clang product is_cross_compiling)
   set(PATH_TO_CLANG_SOURCE "${${product}_PATH_TO_CLANG_SOURCE}")
   set(PATH_TO_CLANG_BUILD "${${product}_PATH_TO_CLANG_BUILD}")
 
+  file(TO_CMAKE_PATH "${PATH_TO_CLANG_SOURCE}" PATH_TO_CLANG_SOURCE)
+  file(TO_CMAKE_PATH "${PATH_TO_CLANG_BUILD}" PATH_TO_CLANG_BUILD)
+
   # Add all Clang CMake paths to our cmake module path.
   set(SWIFT_CLANG_CMAKE_PATHS
     "${PATH_TO_CLANG_BUILD}/share/clang/cmake"
@@ -188,12 +193,17 @@ macro(swift_common_standalone_build_config_cmark product)
     ABSOLUTE)
   get_filename_component(CMARK_LIBRARY_DIR "${${product}_CMARK_LIBRARY_DIR}"
     ABSOLUTE)
+
   set(CMARK_MAIN_INCLUDE_DIR "${CMARK_MAIN_SRC_DIR}/src")
   set(CMARK_BUILD_INCLUDE_DIR "${PATH_TO_CMARK_BUILD}/src")
+
+  file(TO_CMAKE_PATH "${CMARK_MAIN_INCLUDE_DIR}" CMARK_MAIN_INCLUDE_DIR)
+  file(TO_CMAKE_PATH "${CMARK_BUILD_INCLUDE_DIR}" CMARK_BUILD_INCLUDE_DIR)
+
   include_directories("${CMARK_MAIN_INCLUDE_DIR}"
                       "${CMARK_BUILD_INCLUDE_DIR}")
 
-  include(${${product}_PATH_TO_CMARK_BUILD}/src/CMarkExports.cmake)
+  include(${PATH_TO_CMARK_BUILD}/src/CMarkExports.cmake)
   add_definitions(-DCMARK_STATIC_DEFINE)
 endmacro()
 

branches/tensorflow-merge/docs/ByteTree.md

@@ -13,20 +13,20 @@ For example, the string "Hello World" would be encoded as `(uint32_t)11` `"Hello
 
 ## Serialization of objects
 
-An object consists of its size, measured in the number of fields and represented as a `uint_32t` in little endian order, followed by the direct concatenation of its fields. Because each field is again prefixed with its size, no delimites are necessary in between the fields.
+An object consists of its size, measured in the number of fields and represented as a `uint_32t` in little endian order, followed by the direct concatenation of its fields. Because each field is again prefixed with its size, no delimits are necessary in between the fields.
 
-To distinguish scalars and objects, the size of objects has its most-siginificant bit set to 1. It must be ignored to retrieve the number of fields in the object.
+To distinguish scalars and objects, the size of objects has its most-significant bit set to 1. It must be ignored to retrieve the number of fields in the object.
 
 Arrays are modelled as objects whose fields are all of the same type and whose length is variadic (and is indicated by the object's size).
 
 ## Versioning
 
-The ByteTree format is prepended by a 4-byte protocol version number that describes the version of the object tree that was serialized. Its exact semantics are up to each specific application, but it is encouraged to interpret it as a two-comentent number where the first component, consisting of the three most significant bytes, is incremented for breaking changes and the last byte is incremented for backwards-compatible changes.
+The ByteTree format is prepended by a 4-byte protocol version number that describes the version of the object tree that was serialized. Its exact semantics are up to each specific application, but it is encouraged to interpret it as a two-component number where the first component, consisting of the three most significant bytes, is incremented for breaking changes and the last byte is incremented for backwards-compatible changes.
 
-## Forward compatilibity
+## Forward compatibility
 
 Fields may be added to the end of objects in a backwards compatible manner (older deserialisers will still be able to deserialise the format). It does so by skipping over all fields that are not read during deserialisation. Newer versions of the deserialiser can detect if recently added fields are not present in the serialised data by inspecting the `numFields` property passed during deserialisation.
 
 ## Serialization safety
 
-Since all fields in objects are accessed by their index, issues quickly arise if a new field is accidentally added at the beginning of an object. To prevent issues like this, the ByteTree serialiser and deserialiser requires the explicit specification of each field's index within the object. These indicies are never serialised. Their sole purpose is to check that all fields are read in the correct order in assertion builds.
+Since all fields in objects are accessed by their index, issues quickly arise if a new field is accidentally added at the beginning of an object. To prevent issues like this, the ByteTree serialiser and deserialiser requires the explicit specification of each field's index within the object. These indices are never serialised. Their sole purpose is to check that all fields are read in the correct order in assertion builds.

branches/tensorflow-merge/docs/CompilerPerformance.md

@@ -695,7 +695,7 @@ files in `<directory>`.
 
 This option also provides _some_ high-level counters that are "always available"
 regardless of whether you're using an assert or release build, though assert
-builds still get _more_ counters (all of those available thorugh
+builds still get _more_ counters (all of those available through
 `-print-stats`). If you are using a new-enough compiler, `-stats-output-dir`
 often simplifies analysis, since its output is machine-readable and aggregates
 all the jobs in a multi-job compilation, and there's a post-processing script
@@ -1322,7 +1322,7 @@ internals of the compiler, just time and patience.
 
   - Add Open Source projects to the
     [source-compatibility testsuite](https://swift.org/source-compatibility/).
-    Apple's internal CI infastructure is now tracking selected non-assert-build
+    Apple's internal CI infrastructure is now tracking selected non-assert-build
     `UnifiedStatsReporter` counters on those projects, and the team is far
     more likely to catch a regression if it's shown by a project in the testsuite.
 

branches/tensorflow-merge/docs/Random.md

@@ -13,4 +13,4 @@ following implementation details:
 - Linux, FreeBSD, and other UNIX-like platforms use `getrandom(2)` when available;
 otherwise, they read from `/dev/urandom`.
 - Fuchsia platforms use `getentropy(3)`.
-- Windows paltforms use `BCryptGenRandom`.
+- Windows platforms use `BCryptGenRandom`.

branches/tensorflow-merge/docs/SIL.rst

@@ -984,6 +984,7 @@ Linkage
   sil-linkage ::= 'private'
   sil-linkage ::= 'public_external'
   sil-linkage ::= 'hidden_external'
+  sil-linkage ::= 'non_abi'
 
 A linkage specifier controls the situations in which two objects in
 different SIL modules are *linked*, i.e. treated as the same object.
@@ -1048,6 +1049,25 @@ not needed.
 If an object has any uses, then it must be linked to a definition
 with non-external linkage.
 
+Public non-ABI linkage
+``````````````````````
+
+The `non_abi` linkage is a special linkage used for definitions which
+only exist in serialized SIL, and do not define visible symbols in the
+object file.
+
+A definition with `non_abi` linkage behaves like it has `shared` linkage,
+except that it must be serialized in the SIL module even if not referenced
+from anywhere else in the module. For example, this means it is considered
+a root for dead function elimination.
+
+When a `non_abi` definition is deserialized, it will have `shared_external`
+linkage.
+
+There is no `non_abi_external` linkage. Instead, when referencing a
+`non_abi` declaration that is defined in a different translation unit from
+the same Swift module, you must use `hidden_external` linkage.
+
 Summary
 ```````
 
@@ -4750,7 +4770,7 @@ A ``convert_escape_to_noescape [not_guaranteed] %opd`` indicates that the
 lifetime of its operand was not guaranteed by SILGen and a mandatory pass must
 be run to ensure the lifetime of ``%opd``` for the conversion's uses.
 
-A ``convert_escape_to_noescape [escaped]`` indiciates that the result was
+A ``convert_escape_to_noescape [escaped]`` indicates that the result was
 passed to a function (materializeForSet) which escapes the closure in a way not
 expressed by the convert's users. The mandatory pass must ensure the lifetime
 in a conservative way.

branches/tensorflow-merge/docs/SILProgrammersManual.md

@@ -172,7 +172,7 @@ TBD: Possibly link to a separate document explaining the architecture of IRGen.
 ## SILAnalysis and the PassManager
 
 TBD: describe the mechanism by which passes invalidate and update the
-PassManager and its avaiable analyses.
+PassManager and its available analyses.
 
 ## High Level SIL Optimizations
 

branches/tensorflow-merge/docs/Testing.md

@@ -56,23 +56,23 @@ development cycle. To invoke LLVM's `lit.py` script directly, it must be
 configured to use your local build directory. For example:
 
 ```
-    % ${LLVM_SOURCE_ROOT}/utils/lit/lit.py -sv ${SWIFT_BUILD_DIR}/test-iphonesimulator-i386/Parse/
+    % ${LLVM_SOURCE_ROOT}/utils/lit/lit.py -sv ${SWIFT_BUILD_DIR}/test-macosx-x86_64/Parse/
 ```
 
-This runs the tests in the 'test/Parse/' directory targeting the 32-bit iOS
-Simulator. The ``-sv`` options give you a nice progress bar and only show you
+This runs the tests in the 'test/Parse/' directory targeting 64-bit macOS. 
+The ``-sv`` options give you a nice progress bar and only show you
 output from the tests that fail.
 
 One downside of using this form is that you're appending relative paths from
 the source directory to the test directory in your build directory. (That is,
 there may not actually be a directory named 'Parse' in
-'test-iphonesimulator-i386/'; the invocation works because there is one in the
+'test-macosx-x86_64/'; the invocation works because there is one in the
 source 'test/' directory.) There is a more verbose form that specifies the
 testing configuration explicitly, which then allows you to test files
 regardless of location.
 
 ```
-    % ${LLVM_SOURCE_ROOT}/utils/lit/lit.py -sv --param swift_site_config=${SWIFT_BUILD_DIR}/test-iphonesimulator-i386/lit.site.cfg ${SWIFT_SOURCE_ROOT}/test/Parse/
+    % ${LLVM_SOURCE_ROOT}/utils/lit/lit.py -sv --param swift_site_config=${SWIFT_BUILD_DIR}/test-macosx-x86_64/lit.site.cfg ${SWIFT_SOURCE_ROOT}/test/Parse/
 ```
 
 For more complicated configuration, copy the invocation from one of the build

branches/tensorflow-merge/docs/Windows.md

@@ -19,7 +19,7 @@ Currently there are three supported ways to build Swift for Windows.
 `clang-cl` is recommended over MSVC for building Swift on Windows.
 Although it is possible to build the compiler and the standard library with
 MSVC to use those built products to compile a Swift program, it won't be
-possible to run the binary without seperately obtaining the Swift runtime. On
+possible to run the binary without separately obtaining the Swift runtime. On
 the other hand, `clang-cl` is able to build the runtime, which makes it
 possible to build and run all the components required for Swift natively on
 Windows.

branches/tensorflow-merge/docs/WindowsBuild.md

@@ -30,16 +30,31 @@ it provides some of the needed headers and libraries.
   installation.
 
 ### 2. Clone the repositories
+1. Configure git to work with Unix file endings
 1. Create a folder to contain all the Swift repositories
 1. Clone `apple/swift-cmark` into a folder named `cmark`
 1. Clone `apple/swift-clang` into a folder named `clang`
 1. Clone `apple/swift-llvm` into a folder named `llvm`
 1. Clone `apple/swift-compiler-rt` into a folder named `compiler-rt`
 1. Clone `apple/swift` into a folder named `swift`
 1. Clone `apple/swift-corelibs-libdispatch` into a folder named `swift-corelibs-libdispatch`
+1. Clone `apple/swift-corelibs-foundation` into a folder name `swift-corelibs-foundation`
+
 - Currently, other repositories in the Swift project have not been tested and
   may not be supported.
 
+```cmd
+git config --global core.autocrlf input
+S:
+git clone https://github.com/apple/swift-cmark cmark
+git clone https://github.com/apple/swift-clang clang
+git clone https://github.com/apple/swift-llvm llvm
+git clone https://github.com/apple/swift-compiler-rt compiler-rt
+git clone https://github.com/apple/swift
+git clone https://github.com/apple/swift-corelibs-libdispatch
+git clone https://github.com/apple/swift-corelibs-foundation
+```
+
 ### 3. Acquire ICU
 1. Download ICU from [ICU Project](http://site.icu-project.org) for Windows x64 and extract the binaries.
 1. Add the `bin64` folder to your `Path` environment variable.
@@ -186,8 +201,9 @@ Running the testsuite on Windows has additional external dependencies.  You must
 
   1. coreutils
   2. diffutils
-  3. grep
-  4. sed
+  3. file
+  4. grep
+  5. sed
 
 ```cmd
 ninja -C "S:/build/Ninja-DebugAssert/swift-windows-amd64" check-swift

branches/tensorflow-merge/include/swift/AST/DiagnosticsSema.def

@@ -4103,6 +4103,9 @@ ERROR(inlinable_decl_not_public,
       "but %0 is %select{private|fileprivate|internal|%error|%error}1",
       (DeclBaseName, AccessLevel))
 
+ERROR(inlinable_resilient_deinit,
+      none, "deinitializer can only be '@inlinable' if the class is '@_fixed_layout'", ())
+
 //------------------------------------------------------------------------------
 // MARK: @_specialize diagnostics
 //------------------------------------------------------------------------------

branches/tensorflow-merge/include/swift/Basic/type_traits.h

@@ -30,7 +30,7 @@ namespace swift {
 /// is not intended to be specialized.
 template<typename T>
 struct IsTriviallyCopyable {
-#if _LIBCPP_VERSION || SWIFT_COMPILER_IS_MSVC
+#if defined(_LIBCPP_VERSION) || SWIFT_COMPILER_IS_MSVC
   // libc++ and MSVC implement is_trivially_copyable.
   static const bool value = std::is_trivially_copyable<T>::value;
 #elif __has_feature(is_trivially_copyable) || __GNUC__ >= 5
@@ -42,7 +42,7 @@ struct IsTriviallyCopyable {
 
 template<typename T>
 struct IsTriviallyConstructible {
-#if _LIBCPP_VERSION || SWIFT_COMPILER_IS_MSVC
+#if defined(_LIBCPP_VERSION) || SWIFT_COMPILER_IS_MSVC
   // libc++ and MSVC implement is_trivially_constructible.
   static const bool value = std::is_trivially_constructible<T>::value;
 #elif __has_feature(has_trivial_constructor) || __GNUC__ >= 5
@@ -54,7 +54,7 @@ struct IsTriviallyConstructible {
 
 template<typename T>
 struct IsTriviallyDestructible {
-#if _LIBCPP_VERSION || SWIFT_COMPILER_IS_MSVC
+#if defined(_LIBCPP_VERSION) || SWIFT_COMPILER_IS_MSVC
   // libc++ and MSVC implement is_trivially_destructible.
   static const bool value = std::is_trivially_destructible<T>::value;
 #elif __has_feature(has_trivial_destructor) || __GNUC__ >= 5

branches/tensorflow-merge/include/swift/SIL/SILInstruction.h

@@ -326,7 +326,7 @@ class SILInstruction
   /// Update this instruction's SILDebugScope. This function should
   /// never be called directly. Use SILBuilder, SILBuilderWithScope or
   /// SILClonerWithScope instead.
-  void setDebugScope(SILBuilder &B, const SILDebugScope *DS);
+  void setDebugScope(const SILDebugScope *DS);
 
   /// Total number of created and deleted SILInstructions.
   /// It is used only for collecting the compiler statistics.