Suppress nothrow/Exception spec conflict warning when we dont know the ES.

In any situation where the Exception Spec isn't clear, suppress the
warning to avoid false positives.

llvm-svn: 362243

2 files changed, 10 insertions, 7 deletions

diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 43ac435a824..d473fb6c8f3 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -6976,18 +6976,18 @@ static bool handleFunctionTypeAttr(TypeProcessingState &state, ParsedAttr &attr,
       case EST_BasicNoexcept:
       case EST_NoexceptTrue:
       case EST_NoThrow:
-      case EST_Unparsed:
         // Exception spec doesn't conflict with nothrow, so don't warn.
-        // Unparsed is included in this, since method signatures aren't parsed
-        // until after the fact.
+        LLVM_FALLTHROUGH;
+      case EST_Unparsed:
+      case EST_Uninstantiated:
+      case EST_DependentNoexcept:
+      case EST_Unevaluated:
+        // We don't have enough information to properly determine if there is a
+        // conflict, so suppress the warning.
         break;
-
       case EST_Dynamic:
       case EST_MSAny:
       case EST_NoexceptFalse:
-      case EST_DependentNoexcept:
-      case EST_Unevaluated:
-      case EST_Uninstantiated:
         S.Diag(attr.getLoc(), diag::warn_nothrow_attribute_ignored);
         break;
       }
diff --git a/clang/test/SemaCXX/nothrow-vs-exception-specs.cpp b/clang/test/SemaCXX/nothrow-vs-exception-specs.cpp
index 563f6040670..78416d8c0b6 100644
--- a/clang/test/SemaCXX/nothrow-vs-exception-specs.cpp
+++ b/clang/test/SemaCXX/nothrow-vs-exception-specs.cpp
@@ -54,6 +54,9 @@ __declspec(nothrow) void foo5() noexcept(noexcept(foo2()));
 // expected-warning@+1{{'nothrow' attribute conflicts with exception specification; attribute ignored}}
 __declspec(nothrow) void foo6() noexcept(noexcept(foo3()));
 
+template<typename F>
+__declspec(nothrow) void foo7() noexcept(noexcept(F()));
+
 // FIXME: It would be nice to be able to warn on these, however at the time we
 // evaluate the nothrow, these have yet to be parsed, so the data is not yet
 // there.