llvm-project/clang/test/SemaCXX/cxx0x-defaulted-functions.cpp

247 lines
7.9 KiB
C++
Raw Normal View History

// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify -fcxx-exceptions %s
void fn() = default; // expected-error {{only special member}}
struct foo {
void fn() = default; // expected-error {{only special member}}
foo() = default;
foo(const foo&) = default;
foo(foo&&) = default;
foo& operator = (const foo&) = default;
foo& operator = (foo&&) = default;
~foo() = default;
};
struct bar {
bar();
bar(const bar&);
bar(bar&&);
bar& operator = (const bar&);
bar& operator = (bar&&);
~bar();
};
bar::bar() = default;
bar::bar(const bar&) = default;
bar::bar(bar&&) = default;
bar& bar::operator = (const bar&) = default;
bar& bar::operator = (bar&&) = default;
bar::~bar() = default;
static_assert(__is_trivial(foo), "foo should be trivial");
static_assert(!__has_trivial_destructor(bar), "bar's destructor isn't trivial");
static_assert(!__has_trivial_constructor(bar),
"bar's default constructor isn't trivial");
static_assert(!__has_trivial_copy(bar), "bar has no trivial copy");
static_assert(!__has_trivial_assign(bar), "bar has no trivial assign");
void tester() {
foo f, g(f);
bar b, c(b);
f = g;
b = c;
}
template<typename T> struct S : T {
constexpr S() = default;
constexpr S(const S&) = default;
constexpr S(S&&) = default;
};
struct lit { constexpr lit() {} };
S<lit> s_lit; // ok
S<bar> s_bar; // ok
struct Friends {
friend S<bar>::S();
friend S<bar>::S(const S&);
friend S<bar>::S(S&&);
};
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
namespace DefaultedFnExceptionSpec {
// DR1330: The exception-specification of an implicitly-declared special
// member function is evaluated as needed.
template<typename T> T &&declval();
template<typename T> struct pair {
pair(const pair&) noexcept(noexcept(T(declval<T>())));
};
struct Y;
struct X { X(); X(const Y&); };
struct Y { pair<X> p; };
template<typename T>
struct A {
pair<T> p;
};
struct B {
B();
B(const A<B>&);
};
// Don't crash here.
void f() {
X x = X();
(void)noexcept(B(declval<B>()));
}
template<typename T>
struct Error {
void f() noexcept(T::error);
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
Error() noexcept(T::error); // expected-error {{type 'int' cannot be used prior to '::' because it has no members}} expected-error {{type 'char'}}
Error(const Error&) noexcept(T::error); // expected-error {{type 'int' cannot be used prior to '::' because it has no members}}
Error(Error&&) noexcept(T::error); // expected-error {{type 'int' cannot be used prior to '::' because it has no members}}
Error &operator=(const Error&) noexcept(T::error); // expected-error {{type 'int' cannot be used prior to '::' because it has no members}} expected-error {{type 'double'}}
Error &operator=(Error&&) noexcept(T::error); // expected-error {{type 'int' cannot be used prior to '::' because it has no members}}
~Error() noexcept(T::error); // expected-error {{type 'int' cannot be used prior to '::' because it has no members}} expected-error {{type 'char'}}
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
};
Error<char> c; // expected-note 2{{instantiation of}}
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
struct DelayImplicit {
// FIXME: The location of this note is terrible. The instantiation was
// triggered by the uses of the functions in the decltype expressions below.
Error<int> e; // expected-note 6{{instantiation of}}
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
};
Error<float> *e;
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
// An exception specification is needed if the exception specification for a
// a defaulted special member function that calls the function is needed.
// Use in an unevaluated operand still results in the exception spec being
// needed.
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
void test1(decltype(declval<DelayImplicit>() = DelayImplicit(DelayImplicit())));
void test2(decltype(declval<DelayImplicit>() = declval<const DelayImplicit>()));
void test3(decltype(DelayImplicit(declval<const DelayImplicit>())));
// Any odr-use needs the exception specification.
void f(Error<double> *p) {
*p = *p; // expected-note {{instantiation of}}
}
Final piece of core issue 1330: delay computing the exception specification of a defaulted special member function until the exception specification is needed (using the same criteria used for the delayed instantiation of exception specifications for function temploids). EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to resolve the exception specification. This is enabled for all C++ modes: it's a little faster in the case where the exception specification isn't used, allows our C++11-in-C++98 extensions to work, and is still correct for C++98, since in that mode the computation of the exception specification can't fail. The diagnostics here aren't great (in particular, we should include implicit evaluation of exception specifications for defaulted special members in the template instantiation backtraces), but they're not much worse than before. Our approach to the problem of cycles between in-class initializers and the exception specification for a defaulted default constructor is modified a little by this change -- we now reject any odr-use of a defaulted default constructor if that constructor uses an in-class initializer and the use is in an in-class initialzer which is declared lexically earlier. This is a closer approximation to the current draft solution in core issue 1351, but isn't an exact match (but the current draft wording isn't reasonable, so that's to be expected). llvm-svn: 160847
2012-07-27 12:22:15 +08:00
}
namespace PR13527 {
struct X {
X() = delete; // expected-note {{here}}
X(const X&) = delete; // expected-note {{here}}
X(X&&) = delete; // expected-note {{here}}
X &operator=(const X&) = delete; // expected-note {{here}}
X &operator=(X&&) = delete; // expected-note {{here}}
~X() = delete; // expected-note {{here}}
};
X::X() = default; // expected-error {{redefinition}}
X::X(const X&) = default; // expected-error {{redefinition}}
X::X(X&&) = default; // expected-error {{redefinition}}
X &X::operator=(const X&) = default; // expected-error {{redefinition}}
X &X::operator=(X&&) = default; // expected-error {{redefinition}}
X::~X() = default; // expected-error {{redefinition}}
struct Y {
Y() = default;
Y(const Y&) = default;
Y(Y&&) = default;
Y &operator=(const Y&) = default;
Y &operator=(Y&&) = default;
~Y() = default;
};
Y::Y() noexcept = default; // expected-error {{definition of explicitly defaulted}}
Y::Y(const Y&) noexcept = default; // expected-error {{definition of explicitly defaulted}}
Y::Y(Y&&) noexcept = default; // expected-error {{definition of explicitly defaulted}}
Y &Y::operator=(const Y&) noexcept = default; // expected-error {{definition of explicitly defaulted}}
Y &Y::operator=(Y&&) noexcept = default; // expected-error {{definition of explicitly defaulted}}
Y::~Y() = default; // expected-error {{definition of explicitly defaulted}}
}
namespace PR27699 {
struct X {
X();
};
X::X() = default; // expected-note {{here}}
X::X() = default; // expected-error {{redefinition of 'X'}}
}
namespace PR14577 {
template<typename T>
struct Outer {
template<typename U>
struct Inner1 {
~Inner1();
};
template<typename U>
struct Inner2 {
~Inner2();
};
};
template<typename T>
Outer<T>::Inner1<T>::~Inner1() = delete; // expected-error {{nested name specifier 'Outer<T>::Inner1<T>::' for declaration does not refer into a class, class template or class template partial specialization}} expected-error {{only functions can have deleted definitions}}
template<typename T>
Outer<T>::Inner2<T>::~Inner2() = default; // expected-error {{nested name specifier 'Outer<T>::Inner2<T>::' for declaration does not refer into a class, class template or class template partial specialization}} expected-error {{only special member functions may be defaulted}}
}
extern "C" { // expected-note {{extern "C" language linkage specification begins here}}
template<typename _Tp> // expected-error {{templates must have C++ linkage}}
void PR13573(const _Tp&) = delete;
}
namespace PR15597 {
template<typename T> struct A {
A() noexcept(true) = default;
~A() noexcept(true) = default;
};
template<typename T> struct B {
B() noexcept(false) = default; // expected-error {{does not match the calculated one}}
~B() noexcept(false) = default; // expected-error {{does not match the calculated one}}
};
A<int> a;
B<int> b; // expected-note {{here}}
}
namespace PR27941 {
struct ExplicitBool {
ExplicitBool &operator=(bool) = default; // expected-error{{only special member functions may be defaulted}}
int member;
};
int fn() {
ExplicitBool t;
t = true;
}
}
namespace dependent_classes {
template <bool B, typename X, typename Y>
struct conditional;
template <typename X, typename Y>
struct conditional<true, X, Y> { typedef X type; };
template <typename X, typename Y>
struct conditional<false, X, Y> { typedef Y type; };
template<bool B> struct X {
X();
// B == false triggers error for = default.
using T = typename conditional<B, const X &, int>::type;
X(T) = default; // expected-error {{only special member functions}}
// Either value of B creates a constructor that can be default
using U = typename conditional<B, X&&, const X&>::type;
X(U) = default;
};
X<true> x1;
X<false> x2; // expected-note {{in instantiation}}
template <typename Type>
class E {
explicit E(const int &) = default;
};
template <typename Type>
E<Type>::E(const int&) {} // expected-error {{definition of explicitly defaulted function}}
}