destructors.
We previously tried to patch up the exception specification after
completing the class, which went wrong when the exception specification
was needed within the class body (in particular, by a friend
redeclaration of the destructor in a nested class). We now mark the
destructor as having a not-yet-computed exception specification
immediately after creating it.
This requires delaying various checks against the exception
specification (where we'd previously have just got the wrong exception
specification, and now find we have an exception specification that we
can't compute yet) when those checks fire while the class is being
defined.
This also exposed an issue that we were missing a CodeSynthesisContext
for computation of exception specifications (otherwise we'd fail to make
the module containing the definition of the class visible when computing
its members' exception specs). Adding that incidentally also gives us a
diagnostic quality improvement.
This has also exposed an pre-existing problem: making the exception
specification evaluation context a non-SFINAE context (as it should be)
results in a bootstrap failure; PR38850 filed for this.
llvm-svn: 341499
This commit improves the "must have C++ linkage" error diagnostics that are
emitted for C++ declarations like templates and literal operators by adding an
additional note that points to the appropriate extern "C" linkage specifier.
rdar://19021120
Differential Revision: https://reviews.llvm.org/D26189
llvm-svn: 285823
not instantiate exception specifications of functions if they were only used in
unevaluated contexts (other than 'noexcept' expressions).
In C++17 onwards, this becomes essential since the exception specification is
now part of the function's type.
Note that this means that constructs like the following no longer work:
struct A {
static T f() noexcept(...);
decltype(f()) *p;
};
... because the decltype expression now needs the exception specification of
'f', which has not yet been parsed.
llvm-svn: 284549
With templated classes, is possible to not be able to determine is a member
function is a special member function before the class is instantiated. Only
these special member functions can be defaulted. In some cases, knowing
whether a function is a special member function can't be determined until
instantiation, so an uninstantiated function could possibly be defaulted too.
Add a case to the error diagnostic when the function marked with a default is
not known to be a special member function.
llvm-svn: 282989
In some cases, non-special member functions were being marked as being defaulted
in templated classes. This can cause interactions with later code that expects
the default function to be one of the specific member functions. Fix the check
so that templated class members are checked the same way as non-templated class
members are.
llvm-svn: 282547
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
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
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
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
Richard Smith