Commit Graph

11 Commits

Author SHA1 Message Date
David Majnemer 8e1a913cfa Sema: Recover when a function template is in an extern "C" block
llvm-svn: 226135
2015-01-15 07:04:38 +00:00
Richard Smith 3901dfe431 PR15597: Fix a confusion between the implicit exception specification and the
uninstantiated exception specification when a special member within a class
template is both defaulted and given an exception specification on its first
declaration.

llvm-svn: 178103
2013-03-27 00:22:47 +00:00
Benjamin Kramer e08de37902 Add the testcase from PR13573, this used to crash.
The error is a bit strange tbh, but better than crashing.

llvm-svn: 175996
2013-02-24 15:51:32 +00:00
Aaron Ballman f96361e6cb Fixes crash when illegal function definitions are deleted or defaulted. Fixes PR14577.
llvm-svn: 172676
2013-01-16 23:39:10 +00:00
Richard Smith f716bb859b PR13527: don't assert if a function is explicitly defaulted when it's already
been defined.

llvm-svn: 161315
2012-08-06 02:25:10 +00:00
Richard Smith d3b5c90865 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 04:22:15 +00:00
Richard Smith 337a5a1c3f Allow friend declarations of defaulted special member functions. Only
definitions of such members are prohibited, not mere declarations.

llvm-svn: 158186
2012-06-08 01:30:54 +00:00
Richard Smith b9e90b13cf Fold the six functions checking explicitly-defaulted special member functions
into one. These were all performing almost identical checks, with different bugs
in each of them.

This fixes PR12806 (we weren't setting the exception specification for an
explicitly-defaulted, non-user-provided default constructor) and enforces
8.4.2/2's rule that an in-class defaulted member must exactly match the implicit
parameter type.

llvm-svn: 156802
2012-05-15 04:39:51 +00:00
Richard Smith e7f5de485e Fix another issue introduced by the proposed wording for core issue 1358: since
the instantiation of a constexpr function temploid is now always constexpr, a
defaulted constexpr function temploid is often ill-formed by the rule in
[dcl.fct.def.default]p2 that an explicitly-defaulted constexpr function must
have a constexpr implicit definition. To avoid making loads of completely
reasonable code ill-formed, do not apply that rule to templates.

llvm-svn: 150453
2012-02-14 02:33:50 +00:00
Richard Smith 9ca5c42582 Update all tests other than Driver/std.cpp to use -std=c++11 rather than
-std=c++0x. Patch by Ahmed Charles!

llvm-svn: 141900
2011-10-13 22:29:44 +00:00
Alexis Hunt 8b4551844c Implement some tests for defaulted constructors. To do this I had to
suppress an error we were previously emitting on valid union code.

llvm-svn: 131440
2011-05-17 00:19:05 +00:00