PR38627: Fix handling of exception specification adjustment for

destructors.

We previously tried to patch up the exception specification after
completing the class, which went wrong when the exception specification
was needed within the class body (in particular, by a friend
redeclaration of the destructor in a nested class). We now mark the
destructor as having a not-yet-computed exception specification
immediately after creating it.

This requires delaying various checks against the exception
specification (where we'd previously have just got the wrong exception
specification, and now find we have an exception specification that we
can't compute yet) when those checks fire while the class is being
defined.

This also exposed an issue that we were missing a CodeSynthesisContext
for computation of exception specifications (otherwise we'd fail to make
the module containing the definition of the class visible when computing
its members' exception specs). Adding that incidentally also gives us a
diagnostic quality improvement.

This has also exposed an pre-existing problem: making the exception
specification evaluation context a non-SFINAE context (as it should be)
results in a bootstrap failure; PR38850 filed for this.

llvm-svn: 341499

1 files changed, 10 insertions, 12 deletions

diff --git a/clang/test/SemaCXX/implicit-exception-spec.cpp b/clang/test/SemaCXX/implicit-exception-spec.cpp
index c21f773e94c..19d645d6d3d 100644
--- a/clang/test/SemaCXX/implicit-exception-spec.cpp
+++ b/clang/test/SemaCXX/implicit-exception-spec.cpp
@@ -16,41 +16,39 @@ namespace InClassInitializers {
   // Noexcept::Noexcept is not declared constexpr, therefore noexcept(Noexcept())
   // is false.
   bool ThrowSomething() noexcept(false);
-  struct ConstExpr {
+  struct ConstExpr { // expected-error {{default member initializer for 'b' needed}}
     bool b = // expected-note {{declared here}}
-      noexcept(ConstExpr()) && ThrowSomething(); // expected-error {{default member initializer for 'b' needed}}
+      noexcept(ConstExpr()) && ThrowSomething(); // expected-note {{in evaluation of exception spec}}
   };
 
   // Much more obviously broken: we can't parse the initializer without already
   // knowing whether it produces a noexcept expression.
-  struct TemplateArg {
+  struct TemplateArg { // expected-error {{default member initializer for 'n' needed}}
     int n = // expected-note {{declared here}}
-      ExceptionIf<noexcept(TemplateArg())>::f(); // expected-error {{default member initializer for 'n' needed}}
+      ExceptionIf<noexcept(TemplateArg())>::f(); // expected-note {{in evaluation of exception spec}}
   };
 
   // And within a nested class.
   struct Nested {
-    struct Inner {
+    struct Inner { // expected-error {{default member initializer for 'n' needed}}
       int n = // expected-note {{declared here}}
-        ExceptionIf<noexcept(Nested())>::f();
-    } inner; // expected-error {{default member initializer for 'n' needed}}
+        ExceptionIf<noexcept(Nested())>::f(); // expected-note {{in evaluation of exception spec}}
+    } inner; // expected-note {{in evaluation of exception spec}}
   };
 
   struct Nested2 {
     struct Inner;
-    int n = Inner().n; // expected-error {{initializer for 'n' needed}}
-    struct Inner {
+    int n = Inner().n; // expected-note {{in evaluation of exception spec}}
+    struct Inner { // expected-error {{initializer for 'n' needed}}
       int n = ExceptionIf<noexcept(Nested2())>::f(); // expected-note {{declared here}}
     } inner;
   };
 }
 
 namespace ExceptionSpecification {
-  // FIXME: This diagnostic is quite useless; we should indicate whose
-  // exception specification we were looking for and why.
   struct Nested {
     struct T {
-      T() noexcept(!noexcept(Nested()));
+      T() noexcept(!noexcept(Nested())); // expected-note {{in evaluation of exception spec}}
     } t; // expected-error{{exception specification is not available until end of class definition}}
   };
 }