Now that we check visibility attributes in an appropriate order,

there is no need for mergeVisibily to ever increase the visibility. Not
doing so lets us replace an incorrect use of mergeVisibilityWithMin. The
testcase

struct HIDDEN RECT {
  int top;
};
DEFAULT RECT foo = {0};

shows that we should give preference to one of the attributes instead of
keeping the minimum. We still get this testcase wrong because mergeVisibily
handles two explicit visibilities incorrectly, but this is a step in the
right direction.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155101 91177308-0d34-0410-b5e6-96231b3b80d8

2 files changed, 5 insertions, 1 deletions

diff --git a/include/clang/AST/Decl.h b/include/clang/AST/Decl.h
index 885286408b..0bf4615ca2 100644
--- a/include/clang/AST/Decl.h
+++ b/include/clang/AST/Decl.h
@@ -258,6 +258,10 @@ public:
     // down to one of its members. If the member has no explicit visibility,
     // the class visibility wins.
     void mergeVisibility(Visibility V, bool E = false) {
+      // Never increase the visibility
+      if (visibility() < V)
+        return;
+
       // If one has explicit visibility and the other doesn't, keep the
       // explicit one.
       if (visibilityExplicit() && !E)
diff --git a/lib/AST/Decl.cpp b/lib/AST/Decl.cpp
index f26747bdf6..f4c0aa3c6b 100644
--- a/lib/AST/Decl.cpp
+++ b/lib/AST/Decl.cpp
@@ -327,7 +327,7 @@ static LinkageInfo getLVForNamespaceScopeDecl(const NamedDecl *D, LVFlags F) {
       LinkageInfo TypeLV = getLVForType(Var->getType());
       if (TypeLV.linkage() != ExternalLinkage)
         return LinkageInfo::uniqueExternal();
-      LV.mergeVisibilityWithMin(TypeLV);
+      LV.mergeVisibility(TypeLV);
     }
 
     if (Var->getStorageClass() == SC_PrivateExtern)