1 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
4 A::A() { } // expected-error {{definition of implicitly declared default constructor}}
7 B::B(const B&) { } // expected-error {{definition of implicitly declared copy constructor}}
10 C& C::operator=(const C&) { return *this; } // expected-error {{definition of implicitly declared copy assignment operator}}
13 D::~D() { } // expected-error {{definition of implicitly declared destructor}}
15 // Make sure that the special member functions are introduced for
16 // name-lookup purposes and overload with user-declared
17 // constructors and assignment operators.
30 B& operator = (const A& a) {
44 // If the lazy declaration of special member functions is triggered
45 // in an out-of-line initializer, make sure the functions aren't in
46 // the initializer scope. This used to crash Clang:
55 template<typename T> struct InvokeCopyConstructor {
56 static const T &get();
57 typedef decltype(T(get())) type; // expected-error {{no matching conver}}
61 // expected-note@-1 {{while substituting deduced template arguments}}
64 typename = typename InvokeCopyConstructor<typename T::type>::type>
65 // expected-note@-1 {{in instantiation of template class}}
67 // expected-note@-1 {{in instantiation of default argument}}
69 struct B { // expected-note {{while declaring the implicit copy constructor for 'B'}}
70 // expected-note@-1 {{candidate constructor (the implicit move }}
71 B(); // expected-note {{candidate constructor not viable}}
74 // Triggering the declaration of B's copy constructor causes overload
75 // resolution to occur for A's copying constructor, which instantiates
76 // InvokeCopyConstructor<B>, which triggers the declaration of B's copy
77 // constructor. Notionally, this happens when we get to the end of the
78 // definition of 'struct B', so there is no declared copy constructor yet.
80 // This behavior is g++-compatible, but isn't exactly right; the class is
81 // supposed to be incomplete when we implicitly declare its special members.
85 // Another case, which isn't ill-formed under our rules. This is inspired by
86 // a problem which occurs when combining CGAL with libstdc++-4.7.
88 template<typename T> T &&declval();
89 template<typename T, typename U> struct pair {
91 template<typename V, typename W,
92 typename = decltype(T(declval<const V&>())),
93 typename = decltype(U(declval<const W&>()))>
94 pair(const pair<V,W> &);
97 template<typename K> struct Line;
99 template<typename K> struct Vector {
100 Vector(const Line<K> &l);
103 template<typename K> struct Point {
107 template<typename K> struct Line {
108 pair<Point<K>, Vector<K>> x;
111 // Trigger declaration of Line copy ctor, which causes substitution into
112 // pair's templated constructor, which triggers instantiation of the
113 // definition of Point's copy constructor, which performs overload resolution
114 // on Vector's constructors, which requires declaring all of Line's
115 // constructors. That should not find a copy constructor (because we've not
116 // declared it yet), but by the time we get all the way back here, we should
117 // find the copy constructor.