---

yaml
---
r: 317431
b: refs/heads/master-rebranch
c: 5ac6283
h: refs/heads/master
i:
  317429: 985fd9f
  317427: 229f7b0
  317423: cfbe951

Author: swift-ci

[refs]

@@ -1457,4 +1457,4 @@ refs/tags/swift-DEVELOPMENT-SNAPSHOT-2019-08-02-a: ddd2b2976aa9bfde5f20fe37f6bd2
 refs/tags/swift-DEVELOPMENT-SNAPSHOT-2019-08-03-a: 171cc166f2abeb5ca2a4003700a8a78a108bd300
 refs/heads/benlangmuir-patch-1: baaebaf39d52f3bf36710d4fe40cf212e996b212
 refs/heads/i-do-redeclare: 8c4e6d5de5c1e3f0a2cedccf319df713ea22c48e
-refs/heads/master-rebranch: 36ad1a41baf025fa84a3472842a05759705fdb53
+refs/heads/master-rebranch: 5ac6283a7fcff6e9f8361b900c2e1e9dca78476c

branches/master-rebranch/docs/ABIStabilityManifesto.md

@@ -213,7 +213,7 @@ ABI stability means nailing down type layout and making decisions about how to h
 
 For all of the areas discussed above, more aggressive layout improvements may be invented in the post-ABI stability future. For example, we may want to explore rearranging and packing nested type data members with outer type data members. Such improvements would have to be done in an ABI-additive fashion through deployment target and/or min-version checking. This may mean that the module file will need to track per-type ABI versioning information.
 
-A potentially out of date description of Swift's current type layout can be found in the [Type Layout docs](https://github.com/apple/swift/blob/master/docs/ABI.rst#type-layout).
+A potentially out of date description of Swift's current type layout can be found in the [Type Layout docs](https://github.com/apple/swift/blob/master/docs/ABI/TypeLayout.rst).
 
 
 ## <a name="metadata"></a>Type Metadata
@@ -230,7 +230,7 @@ Metadata has many historical artifacts in its representation that we want to cle
 
 Stabilizing the ABI means producing a precise technical specification for the fixed part of the metadata layout of all language constructs so that future compilers and tools can continue to read and write them. A prose description is not necessarily needed, though explanations are useful. We will also want to carve out extra space for areas where it is likely to be needed for future functionality [[SR-3731](https://bugs.swift.org/browse/SR-3731)].
 
-For more, but potentially out of date, details see the [Type Metadata docs](https://github.com/apple/swift/blob/master/docs/ABI.rst#type-metadata).
+For more, but potentially out of date, details see the [Type Metadata docs](https://github.com/apple/swift/blob/master/docs/ABI/TypeMetadata.rst).
 
 ### Generic Parameters
 
@@ -284,7 +284,7 @@ In addition to common metadata entries, function type metadata stores informatio
 
 Mangling is used to produce unique symbols. It applies to both external (public) symbols as well as internal or hidden symbols. Only the mangling scheme for external symbols is part of ABI.
 
-ABI stability means a stable mangling scheme, fully specified so that future compilers and tools can honor it. For a potentially out-of-date specification of what the mangling currently looks like, see the [Name Mangling docs](https://github.com/apple/swift/blob/master/docs/ABI.rst#mangling).
+ABI stability means a stable mangling scheme, fully specified so that future compilers and tools can honor it. For a potentially out-of-date specification of what the mangling currently looks like, see the [Name Mangling docs](https://github.com/apple/swift/blob/master/docs/ABI/Mangling.rst).
 
 There are some corner cases currently in the mangling scheme that should be fixed before declaring ABI stability. We need to come up with a canonicalization of generic and protocol requirements to allow for order-agnostic mangling [[SR-3733](https://bugs.swift.org/browse/SR-3733)]. We also may decide to more carefully mangle variadicity of function parameters, etc [[SR-3734](https://bugs.swift.org/browse/SR-3734)]. Most often, though, mangling improvements focus on reducing symbol size.
 

branches/master-rebranch/lib/ClangImporter/ClangImporter.cpp

@@ -2023,7 +2023,7 @@ getClangTopLevelOwningModule(ClangNode Node,
 }
 
 static bool isVisibleFromModule(const ClangModuleUnit *ModuleFilter,
-                                const ValueDecl *VD) {
+                                ValueDecl *VD) {
   assert(ModuleFilter);
 
   auto ContainingUnit = VD->getDeclContext()->getModuleScopeContext();
@@ -2038,24 +2038,34 @@ static bool isVisibleFromModule(const ClangModuleUnit *ModuleFilter,
 
   auto ClangNode = VD->getClangNode();
   if (!ClangNode) {
-    // If we synthesized a ValueDecl, it won't have a Clang node. But so far
-    // all the situations where we synthesize top-level declarations are
-    // situations where we don't have to worry about C redeclarations.
-    // We should only consider the declaration visible from its owning module.
+    // If we synthesized a ValueDecl, it won't have a Clang node. Find the
+    // associated declaration that /does/ have a Clang node, and use that.
     auto *SynthesizedTypeAttr =
         VD->getAttrs().getAttribute<ClangImporterSynthesizedTypeAttr>();
     assert(SynthesizedTypeAttr);
 
-    // When adding new ClangImporterSynthesizedTypeAttr::Kinds, make sure that
-    // the above statement still holds: "we don't want to allow these
-    // declarations to be treated as present in multiple modules".
     switch (SynthesizedTypeAttr->getKind()) {
     case ClangImporterSynthesizedTypeAttr::Kind::NSErrorWrapper:
-    case ClangImporterSynthesizedTypeAttr::Kind::NSErrorWrapperAnon:
+    case ClangImporterSynthesizedTypeAttr::Kind::NSErrorWrapperAnon: {
+      ASTContext &Ctx = ContainingUnit->getASTContext();
+      auto LookupFlags =
+          NominalTypeDecl::LookupDirectFlags::IgnoreNewExtensions;
+      auto WrapperStruct = cast<StructDecl>(VD);
+      TinyPtrVector<ValueDecl *> LookupResults =
+          WrapperStruct->lookupDirect(Ctx.Id_Code, LookupFlags);
+      assert(!LookupResults.empty() && "imported error enum without Code");
+
+      auto CodeEnumIter = llvm::find_if(LookupResults,
+                                        [&](ValueDecl *Member) -> bool {
+        return Member->getDeclContext() == WrapperStruct;
+      });
+      assert(CodeEnumIter != LookupResults.end() &&
+             "could not find Code enum in wrapper struct");
+      assert((*CodeEnumIter)->hasClangNode());
+      ClangNode = (*CodeEnumIter)->getClangNode();
       break;
     }
-
-    return false;
+    }
   }
 
   // Macros can be "redeclared" by putting an equivalent definition in two

branches/master-rebranch/test/ClangImporter/Inputs/custom-modules/RedeclaredErrorEnum/Redeclared.h

@@ -1,7 +1,16 @@
 @import Foundation;
+#ifndef NO_IMPORT_BASE_FROM_REDECLARED
 @import Base;
+#endif
 
 extern NSString * const SomeErrorDomain;
 // typedef NS_ERROR_ENUM(SomeErrorDomain, SomeErrorCode);
 typedef enum SomeErrorCode : long SomeErrorCode;
-enum __attribute__((ns_error_domain(SomeErrorDomain))) SomeErrorCode : long;
+enum __attribute__((ns_error_domain(SomeErrorDomain))) SomeErrorCode : long
+#ifdef NO_IMPORT_BASE_FROM_REDECLARED
+{
+  SomeErrorX,
+  SomeErrorY
+}
+#endif
+;

branches/master-rebranch/test/ClangImporter/enum-error-redeclared.swift

@@ -1,4 +1,10 @@
 // RUN: %target-swift-frontend(mock-sdk: %clang-importer-sdk) -typecheck %s -verify -enable-objc-interop -I %S/Inputs/custom-modules/RedeclaredErrorEnum
+// RUN: %target-swift-frontend(mock-sdk: %clang-importer-sdk) -typecheck %s -verify -enable-objc-interop -I %S/Inputs/custom-modules/RedeclaredErrorEnum -DIMPORT_BASE
+// RUN: %target-swift-frontend(mock-sdk: %clang-importer-sdk) -typecheck %s -verify -enable-objc-interop -I %S/Inputs/custom-modules/RedeclaredErrorEnum -DIMPORT_BASE -Xcc -DNO_IMPORT_BASE_FROM_REDECLARED
+
+#if IMPORT_BASE
+import Base
+#endif
 
 import Redeclared