Relax the construction of a definition for implicit, trivial default

constructors. We perform semantic checking when creating the definition, and
this isn't needed in certain contexts (value initialization) but is in others
(default initialization). This fixes PR7948.

We add explicit code to the default initialization path to ensure the
definition is both present and valid.

Doug, please review. I think this follows your latest suggestion, and it ended
up remarkably cleaner than I anticipated. Also let me know if similar logic
should be followed for destructors and copy-constructors.


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

1 files changed, 7 insertions, 1 deletions

diff --git a/test/SemaCXX/default-constructor-initializers.cpp b/test/SemaCXX/default-constructor-initializers.cpp
index 757332df0b..9da85567be 100644
--- a/test/SemaCXX/default-constructor-initializers.cpp
+++ b/test/SemaCXX/default-constructor-initializers.cpp
@@ -43,7 +43,6 @@ Y4 y4;
 
 // More tests
 
-
 struct Z1 { // expected-error {{must explicitly initialize the reference member 'z'}} \
             // expected-error {{must explicitly initialize the const member 'c1'}}
   int& z;       // expected-note {{declared here}}
@@ -51,5 +50,12 @@ struct Z1 { // expected-error {{must explicitly initialize the reference member
   volatile int v1;
 };
 
+// Test default initialization which *requires* a constructor call for non-POD.
 Z1 z1; // expected-note {{first required here}}
 
+// Ensure that value initialization doesn't use trivial implicit constructors.
+namespace PR7948 {
+  // Note that this is also non-POD to ensure we don't just special case PODs.
+  struct S { const int x; ~S(); };
+  const S arr[2] = { { 42 } };
+}