| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
defaulted special member matches the implicit exception specification.
llvm-svn: 360011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
|
|
|
|
|
|
| |
whether a defaulted special member function should be deleted.
llvm-svn: 195620
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
class. Fixes <rdar://problem/13017229>.
llvm-svn: 174145
|
|
|
|
|
|
|
| |
produces an exception of 'noexcept(false)' and is thus compatible with an
explicit exception specification of 'noexcept(false)'.
llvm-svn: 166404
|
|
|
|
|
|
|
| |
constructor will be used for moving that object, in the computation of its
exception specification.
llvm-svn: 160417
|
|
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
|
|
|
| |
llvm-svn: 132878
|
|
|
|
|
|
| |
whether C++ exceptions are enabled, not exceptions in general. PR9358.
llvm-svn: 126820
|
|
|
|
|
|
| |
copy-assignment operator.
llvm-svn: 107406
|
|
llvm-svn: 107395
|