Fix clang's handling of the copy performed in the second phase of class

copy-initialization. We previously got this wrong in a couple of ways:
 - we only looked for copy / move constructors and constructor templates for
   this copy, and thus would fail to copy in cases where doing so should use
   some other constructor (but see core issue 670),
 - we mishandled the special case for disabling user-defined conversions that
   blocks infinite recursion through repeated application of a copy constructor
   (applying it in slightly too many cases) -- though as far as I can tell,
   this does not ever actually affect the result of overload resolution, and
 - we misapplied the special-case rules for constructors taking a parameter
   whose type is a (reference to) the same class type by incorrectly assuming
   that only happens for copy/move constructors (it also happens for
   constructors instantiated from templates and those inherited from base
   classes).

These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.


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

1 files changed, 1 insertions, 1 deletions

diff --git a/test/SemaCXX/cxx98-compat-pedantic.cpp b/test/SemaCXX/cxx98-compat-pedantic.cpp
index 8b0dcc8713..c72c44ad5f 100644
--- a/test/SemaCXX/cxx98-compat-pedantic.cpp
+++ b/test/SemaCXX/cxx98-compat-pedantic.cpp
@@ -55,7 +55,7 @@ namespace CopyCtorIssues {
     Private(const Private&); // expected-note {{declared private here}}
   };
   struct NoViable {
-    NoViable();
+    NoViable(); // expected-note {{not viable}}
     NoViable(NoViable&); // expected-note {{not viable}}
   };
   struct Ambiguous {