'operator delete' or 'operator delete[]' is an explicit exception
specification. Therefore we should diagnose 'void operator delete(void*)'
instead of 'void operator delete(void*) noexcept'.
This diagnostic remains an ExtWarn, since in practice people don't always
include the exception specification in such a declaration.
llvm-svn: 201002
Implement type trait primitives used in the latest edition of the Microsoft
standard C++ library type_traits header.
With this change we can parse much of the Visual Studio 2013 standard headers,
particularly anything that includes <type_traits>.
Fully implemented, available in all language modes:
* __is_constructible()
* __is_nothrow_constructible()
* __is_nothrow_assignable()
Partially implemented, semantic analysis WIP, available as MS extensions:
* __is_destructible()
* __is_nothrow_destructible()
llvm-svn: 199619
Exception specs are not part of the canonical type, but we shouldn't
drop them just because we merged a noreturn attribute.
Fixes PR17110.
llvm-svn: 190206
statement in constexpr functions. Everything which doesn't require variable
mutation is also allowed as an extension in C++11. 'void' becomes a literal
type to support constexpr functions which return 'void'.
llvm-svn: 180022
constructor. This isn't quite perfect (as usual, we don't handle default
arguments correctly yet, and we don't deal with copy/move constructors for
arguments correctly either, but this will be fixed when we implement core issue
1351.
This completes our support for inheriting constructors.
llvm-svn: 179154
since it also has an implicit exception specification. Downgrade the error to
an extwarn, since at least for operator delete, system headers like to declare
it as 'noexcept' whereas the implicit definition does not have an explicit
exception specification. Move the exception specification for user-declared
'operator delete' functions from the type-as-written into the type, to reflect
reality and to allow us to detect whether there was an implicit exception spec
or not.
llvm-svn: 166372
Disambiguate past such a potential problem, and use the absence of 'typename'
to break ties in favor of a parenthesized thingy being an initializer, if
nothing else in the declaration disambiguates it as declaring a function.
llvm-svn: 156963
We have a new flavor of exception specification, EST_Uninstantiated. A function
type with this exception specification carries a pointer to a FunctionDecl, and
the exception specification for that FunctionDecl is instantiated (if needed)
and used in the place of the function type's exception specification.
When a function template declaration with a non-trivial exception specification
is instantiated, the specialization's exception specification is set to this
new 'uninstantiated' kind rather than being instantiated immediately.
Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs
on-demand. Also, any odr-use of a function triggers the instantiation of its
exception specification (the exception specification could be needed by IRGen).
In passing, fix two places where a DeclRefExpr was created but the corresponding
function was not actually marked odr-used. We used to get away with this, but
don't any more.
Also fix a bug where instantiating an exception specification which refers to
function parameters resulted in a crash. We still have the same bug in default
arguments, which I'll be looking into next.
This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to
parse (and, in very limited testing, support) all of libstdc++4.7's standard
headers.
llvm-svn: 154886
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
This model uses the 'landingpad' instruction, which is pinned to the top of the
landing pad. (A landing pad is defined as the destination of the unwind branch
of an invoke instruction.) All of the information needed to generate the correct
exception handling metadata during code generation is encoded into the
landingpad instruction.
The new 'resume' instruction takes the place of the llvm.eh.resume intrinsic
call. It's lowered in much the same way as the intrinsic is.
llvm-svn: 140049
in a noexcept exception specification because it isn't part of the
canonical type. This ensures that we keep the exact expression written
in the noexcept exception specification, rather than accidentally
"adopting" a previously-written and canonically "equivalent" function
prototype. Fixes PR10087.
llvm-svn: 132998
to be careful to emit landing pads that are always prepared to handle a
cleanup path. This is correct mostly because of the fix to the LLVM
inliner, r132200.
llvm-svn: 132209
Change the interface to expose the new information and deal with the enormous fallout.
Introduce the new ExceptionSpecificationType value EST_DynamicNone to more easily deal with empty throw specifications.
Update the tests for noexcept and fix the various bugs uncovered, such as lack of tentative parsing support.
llvm-svn: 127537
self-host. Hopefully these results hold up on different platforms.
I tried to keep the GNU ObjC runtime happy, but it's hard for me to test.
Reimplement how clang generates IR for exceptions. Instead of creating new
invoke destinations which sequentially chain to the previous destination,
push a more semantic representation of *why* we need the cleanup/catch/filter
behavior, then collect that information into a single landing pad upon request.
Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional
control flow) are generated, since it's actually fairly closely tied in with
the former. Remove the need to track which cleanup scope a block is associated
with.
Document a lot of previously poorly-understood (by me, at least) behavior.
The new framework implements the Horrible Hack (tm), which requires every
landing pad to have a catch-all so that inlining will work. Clang no longer
requires the Horrible Hack just to make exceptions flow correctly within
a function, however. The HH is an unfortunate requirement of LLVM's EH IR.
llvm-svn: 107631
Nick Lewycky