Resolve conflicts with upstream master

docs/ABI/Mangling.rst

@@ -1047,3 +1047,63 @@ Some kinds need arguments, which precede ``Tf``.
 If the first character of the string literal is a digit ``[0-9]`` or an
 underscore ``_``, the identifier for the string literal is prefixed with an
 additional underscore ``_``.
+
+Conventions for foreign symbols
+-------------------------------
+
+Swift interoperates with multiple other languages - C, C++, Objective-C, and
+Objective-C++. Each of these languages defines their own mangling conventions,
+so Swift must take care to follow them. However, these conventions do not cover
+Swift-specific symbols like Swift type metadata for foreign types, so Swift uses
+its own mangling scheme for those symbols.
+
+Importing C and C++ structs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Types imported from C and C++ are imported as if they are located in the ``__C``
+module, regardless of the actual Clang module that they are coming from. This
+can be observed when mangling a Swift function that accepts a C/C++ struct as a
+parameter:
+
+C++ module ``CxxStructModule``:
+
+.. code-block:: c++
+
+  struct CxxStruct {};
+
+  inline void cxxFunction(CxxStruct s) {}
+
+Swift module ``main`` that imports ``CxxStructModule``:
+
+.. code-block:: swift
+
+  import CxxStructModule
+
+  public func swiftFunction(_ s: CxxStruct) {}
+
+Resulting symbols (showing only Itanium-mangled C++ symbols for brevity):
+
+.. code::
+
+  _Z11cxxFunction9CxxStruct // -> cxxFunction(CxxStruct)
+  s4main13swiftFunctionyySo9CxxStructVF // -> main.swiftFunction(__C.CxxStruct) -> ()
+
+The reason for ignoring the Clang module and always putting C and C++ types into
+``__C`` at the Swift ABI level is that the Clang module is not a part of the C
+or C++ ABI. When owners of C and C++ Clang modules decide what changes are
+ABI-compatible or not, they will likely take into account C and C++ ABI, but not
+the Swift ABI. Therefore, Swift ABI can only encode information about a C or C++
+type that the C and C++ ABI already encodes in order to remain compatible with
+future versions of libraries that evolve according to C and C++ ABI
+compatibility principles.
+
+The C/C++ compiler does not generate Swift metadata symbols and value witness
+tables for C and C++ types. To make a foreign type usable in Swift in the same
+way as a native type, the Swift compiler must generate these symbols.
+Specifically, each Swift module that uses a given C or C++ type generates the
+necessary Swift symbols. For the example above the Swift compiler will generate following
+nominal type descriptor symbol for ``CxxStruct`` while compiling the ``main`` module:
+
+.. code::
+
+  sSo9CxxStructVMn // -> nominal type descriptor for __C.CxxStruct

docs/DifferentiableProgramming.md

@@ -893,8 +893,15 @@ extension Perceptron {
 
 ### `@differentiable` function types
 
-A subtype of normal function types with a different runtime representation,
-which stores metadata that allows their values to be differentiated anywhere.
+Differentiable functions are first-class values, identified by a
+`@differentiable` attribute in the function type. A `@differentiable` function
+type is a subtype of its corresponding normal function type (i.e. without a
+`@differentiable` attribute) with an extended ABI, which stores metadata that
+allows their values to be differentiated anywhere the function is passed. A
+`@differentiable(linear)` function type is a subtype of its corresponding
+`@differentiable` function type. A normal function can be implicitly converted
+to a `@differentiable` or `@differentiable(linear)` function with appropriate
+compile-time checks.
 
 ```swift
 func addOne(_ x: Float) -> Float { x + 1 }
@@ -920,8 +927,9 @@ func _(_ x: Float) -> (value: Float,
 
 ### Differential operators
 
-Standard library differentiation APIs that take `@differentiable` functions and
-return derivative functions or compute derivative values.
+Differential operators are APIs defined in the standard library that take
+`@differentiable` functions and return derivative functions or compute
+derivative values.
 
 ```swift
 // In the standard library:
@@ -2318,7 +2326,7 @@ As shown in the
 subsection, a `@differentiable` function value's runtime representation contains
 the original function along with extra information that allows the function to
 be differentiated (or transposed, if it is `@differentiable(linear)`). A
-@differentiable or `@differentiable(linear)` function value can be called like a
+`@differentiable` or `@differentiable(linear)` function value can be called like a
 non-`@differentiable` function. A `@differentiable(linear)` function value can
 be implicitly converted to a `@differentiable` one, which can be implicitly
 converted to a non-`@differentiable` one.

include/swift/SIL/SILValue.h

@@ -41,6 +41,7 @@ class SILLocation;
 class DeadEndBlocks;
 class ValueBaseUseIterator;
 class ValueUseIterator;
+class SILValue;
 
 /// An enumeration which contains values for all the concrete ValueBase
 /// subclasses.
@@ -188,6 +189,12 @@ struct ValueOwnershipKind {
     return merge(other).hasValue();
   }
 
+  /// Returns isCompatibleWith(other.getOwnershipKind()).
+  ///
+  /// Definition is inline after SILValue is defined to work around circular
+  /// dependencies.
+  bool isCompatibleWith(SILValue other) const;
+
   template <typename RangeTy>
   static Optional<ValueOwnershipKind> merge(RangeTy &&r) {
     auto initial = Optional<ValueOwnershipKind>(ValueOwnershipKind::None);
@@ -440,6 +447,10 @@ class SILValue {
   void verifyOwnership(DeadEndBlocks *DEBlocks = nullptr) const;
 };
 
+inline bool ValueOwnershipKind::isCompatibleWith(SILValue other) const {
+  return isCompatibleWith(other.getOwnershipKind());
+}
+
 /// A map from a ValueOwnershipKind that an operand can accept to a
 /// UseLifetimeConstraint that describes the effect that the operand's use has
 /// on the underlying value. If a ValueOwnershipKind is not in this map then

include/swift/SILOptimizer/Utils/SILSSAUpdater.h

@@ -18,9 +18,14 @@
 #include "swift/SIL/SILValue.h"
 
 namespace llvm {
-  template<typename T> class SSAUpdaterTraits;
-  template<typename T> class SmallVectorImpl;
-}
+
+template <typename T>
+class SSAUpdaterTraits;
+
+template <typename T>
+class SmallVectorImpl;
+
+} // namespace llvm
 
 namespace swift {
 
@@ -31,7 +36,7 @@ class SILUndef;
 
 /// Independent utility that canonicalizes BB arguments by reusing structurally
 /// equivalent arguments and replacing the original arguments with casts.
-SILValue replaceBBArgWithCast(SILPhiArgument *Arg);
+SILValue replaceBBArgWithCast(SILPhiArgument *arg);
 
 /// This class updates SSA for a set of SIL instructions defined in multiple
 /// blocks.
@@ -40,38 +45,38 @@ class SILSSAUpdater {
 
   // A map of basic block to available phi value.
   using AvailableValsTy = llvm::DenseMap<SILBasicBlock *, SILValue>;
-  std::unique_ptr<AvailableValsTy> AV;
+  std::unique_ptr<AvailableValsTy> blockToAvailableValueMap;
 
-  SILType ValType;
+  SILType type;
 
   // The SSAUpdaterTraits specialization uses this sentinel to mark 'new' phi
   // nodes (all the incoming edge arguments have this sentinel set).
-  std::unique_ptr<SILUndef, void(*)(SILUndef *)> PHISentinel;
+  std::unique_ptr<SILUndef, void (*)(SILUndef *)> phiSentinel;
 
   // If not null updated with inserted 'phi' nodes (SILArgument).
-  SmallVectorImpl<SILPhiArgument *> *InsertedPHIs;
+  SmallVectorImpl<SILPhiArgument *> *insertedPhis;
 
   // Not copyable.
   void operator=(const SILSSAUpdater &) = delete;
   SILSSAUpdater(const SILSSAUpdater &) = delete;
 
 public:
   explicit SILSSAUpdater(
-      SmallVectorImpl<SILPhiArgument *> *InsertedPHIs = nullptr);
+      SmallVectorImpl<SILPhiArgument *> *insertedPhis = nullptr);
   ~SILSSAUpdater();
 
-  void setInsertedPhis(SmallVectorImpl<SILPhiArgument *> *insertedPhis) {
-    InsertedPHIs = insertedPhis;
+  void setInsertedPhis(SmallVectorImpl<SILPhiArgument *> *inputInsertedPhis) {
+    insertedPhis = inputInsertedPhis;
   }
 
   /// Initialize for a use of a value of type.
-  void Initialize(SILType T);
+  void initialize(SILType type);
 
-  bool HasValueForBlock(SILBasicBlock *BB) const;
-  void AddAvailableValue(SILBasicBlock *BB, SILValue V);
+  bool hasValueForBlock(SILBasicBlock *block) const;
+  void addAvailableValue(SILBasicBlock *block, SILValue value);
 
   /// Construct SSA for a value that is live at the *end* of a basic block.
-  SILValue GetValueAtEndOfBlock(SILBasicBlock *BB);
+  SILValue getValueAtEndOfBlock(SILBasicBlock *block);
 
   /// Construct SSA for a value that is live in the middle of a block.
   /// This handles the case where the use is before a definition of the value.
@@ -85,15 +90,15 @@ class SILSSAUpdater {
   ///
   /// In this case we need to insert a 'PHI' node at the beginning of BB2
   /// merging val_1 and val_2.
-  SILValue GetValueInMiddleOfBlock(SILBasicBlock *BB);
+  SILValue getValueInMiddleOfBlock(SILBasicBlock *block);
 
-  void RewriteUse(Operand &Op);
+  void rewriteUse(Operand &operand);
 
-  void *allocate(unsigned Size, unsigned Align) const;
-  static void deallocateSentinel(SILUndef *U);
-private:
+  void *allocate(unsigned size, unsigned align) const;
+  static void deallocateSentinel(SILUndef *undef);
 
-  SILValue GetValueAtEndOfBlockInternal(SILBasicBlock *BB);
+private:
+  SILValue getValueAtEndOfBlockInternal(SILBasicBlock *block);
 };
 
 /// Utility to wrap 'Operand's to deal with invalidation of
@@ -112,15 +117,15 @@ class SILSSAUpdater {
 /// identify the use allowing us to reconstruct the use after the branch has
 /// been changed.
 class UseWrapper {
-  Operand *U;
-  SILBasicBlock *Parent;
+  Operand *wrappedUse;
+  SILBasicBlock *parent;
   enum {
     kRegularUse,
     kBranchUse,
     kCondBranchUseTrue,
     kCondBranchUseFalse
-  } Type;
-  unsigned Idx;
+  } type;
+  unsigned index;
 
 public:
 
@@ -131,7 +136,7 @@ class UseWrapper {
   /// (ValueUseIterator) become invalid as they point to freed operands.
   /// Instead we store the branch's parent and the idx so that we can
   /// reconstruct the use.
-  UseWrapper(Operand *Use);
+  UseWrapper(Operand *use);
 
   Operand *getOperand();