summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/special/class.ctor
Commit message (Collapse)AuthorAgeFilesLines
* [cxx2a] P0641R2: (Some) type mismatches on defaulted functions onlyRichard Smith2018-09-281-1/+1
| | | | | | | | | | | | | | | | render the function deleted instead of rendering the program ill-formed. This change also adds an enabled-by-default warning for the case where an explicitly-defaulted special member function of a non-template class is implicitly deleted by the type checking rules. (This fires either due to this language change or due to pre-C++20 reasons for the member being implicitly deleted). I've tested this on a large codebase and found only bugs (where the program means something that's clearly different from what the programmer intended), so this is enabled by default, but we should revisit this if there are problems with this being enabled by default. llvm-svn: 343285
* Fold -Wreturn-stack-address into general initialization lifetimeRichard Smith2018-07-231-1/+1
| | | | | | checking. llvm-svn: 337743
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-1/+5
| | | | | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. This reinstates r337226, reverted in r337255, with a fix for the InitializedEntity alignment problem that was breaking ARM buildbots. llvm-svn: 337329
* Temporarily revert r337226 "Restructure checking for, and warning on, ↵Florian Hahn2018-07-171-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | lifetime extension." This change breaks on ARM because pointers to clang::InitializedEntity are only 4 byte aligned and do not have 3 bits to store values. A possible solution would be to change the fields in clang::InitializedEntity to enforce a bigger alignment requirement. The error message is llvm/include/llvm/ADT/PointerIntPair.h:132:3: error: static_assert failed "PointerIntPair with integer size too large for pointer" static_assert(IntBits <= PtrTraits::NumLowBitsAvailable, include/llvm/ADT/PointerIntPair.h:73:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> >' requested here Value = Info::updateInt(Info::updatePointer(0, PtrVal), llvm/include/llvm/ADT/PointerIntPair.h:51:5: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::setPointerAndInt' requested here setPointerAndInt(PtrVal, IntVal); ^ llvm/tools/clang/lib/Sema/SemaInit.cpp:6237:12: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::PointerIntPair' requested here return {Entity, LK_Extended}; Full log here: http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/1330 http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/1394 llvm-svn: 337255
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-1/+5
| | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. llvm-svn: 337226
* Move detection of reference members binding to temporaries from building ofRichard Smith2013-06-121-1/+1
| | | | | | | CXXCtorInitializers to the point where we perform the questionable lifetime extension. This exposed a selection of false negatives in the warning. llvm-svn: 183869
* Add a test for r174980, that we used to acceptDmitri Gribenko2013-02-121-2/+10
| | | | llvm-svn: 175005
* Accept over-qualified constructor in MSVC emulation modeDmitri Gribenko2013-02-121-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MSVC accepts this: class A { A::A(); }; Clang accepts regular member functions with extra qualification as an MS extension, but not constructors. This changes the parser to defer rejecting qualified constructors so that the same Sema logic can apply to constructors as regular member functions. This also improves the error message when MS extensions are disabled (in my opinion). Before it was: /Users/jason/Desktop/test.cpp:2:8: error: expected member name or ';' after declaration specifiers A::A(); ~~~~ ^ 1 error generated. After: /Users/jason/Desktop/test.cpp:2:6: error: extra qualification on member 'A' A::A(); ~~~^ 1 error generated. Patch by Jason Haslam. llvm-svn: 174980
* PR14558: Compute triviality of special members (etc) at the end of the classRichard Smith2012-12-111-0/+12
| | | | | | | | | definition, rather than at the end of the definition of the set of nested classes. We still defer checking of the user-specified exception specification to the end of the nesting -- we can't check that until we've parsed the in-class initializers for non-static data members. llvm-svn: 169805
* Properly compute triviality for explicitly-defaulted or deleted special members.Richard Smith2012-12-081-10/+25
| | | | | | | | | | | | | | Remove pre-standard restriction on explicitly-defaulted copy constructors with 'incorrect' parameter types, and instead just make those special members non-trivial as the standard requires. This required making CXXRecordDecl correctly handle classes which have both a trivial and a non-trivial special member of the same kind. This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the new triviality computation technology. llvm-svn: 169667
* Prior to adding the new "expected-no-diagnostics" directive to ↵Andy Gibbs2012-10-191-0/+1
| | | | | | VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. llvm-svn: 166280
* A union can have a constexpr defaulted default constructor, if it has anRichard Smith2012-05-071-0/+39
| | | | | | | | | in-class initializer for one of its fields. Value-initialization of such a type should use the in-class initializer! The former was just a bug, the latter is a (reported) standard defect. llvm-svn: 156274
* [class.copy]p23: Fix an assertion caused by incorrect argument numbering in aRichard Smith2012-04-291-3/+3
| | | | | | | diagnostic, add a test for this paragraph, and tighten up the diagnostic wording a little. llvm-svn: 155784
* Finish PR10217: Ensure we say that a special member was implicitly, notRichard Smith2012-04-021-5/+3
| | | | | | explicitly, deleted in all relevant cases, and explain why. llvm-svn: 153894
* PR10217: Provide diagnostics explaining why an implicitly-deleted specialRichard Smith2012-03-301-25/+34
| | | | | | member function is deleted. llvm-svn: 153773
* Ensure that we delete default constructors in the right cases. Don't delete theRichard Smith2012-02-271-11/+16
| | | | | | | default constructor of a union if it has a const member with no user-provided default constructor. llvm-svn: 151516
* Special members which are defaulted or deleted on their first declaration areRichard Smith2012-02-261-5/+2
| | | | | | | | | | | | | trivial if the implicit declaration would be. Don't forget to set the Trivial flag on the special member as well as on the class. It doesn't seem ideal that we have two separate mechanisms for storing this information, but this patch does not attempt to address that. This leaves us in an interesting position where the has_trivial_X trait for a class says 'yes' for a deleted but trivial X, but is_trivially_Xable says 'no'. This seems to be what the standard requires. llvm-svn: 151465
* When overload resolution picks an implicitly-deleted special memberDouglas Gregor2012-02-151-27/+30
| | | | | | | | | function, provide a specialized diagnostic that indicates the kind of special member function (default constructor, copy assignment operator, etc.) and that it was implicitly deleted. Add a hook where we can provide more detailed information later. llvm-svn: 150611
* Update constexpr implementation to match CWG's chosen approach for core issuesRichard Smith2012-02-131-3/+3
| | | | | | | | | | | | | | | | | | | | 1358, 1360, 1452 and 1453. - Instantiations of constexpr functions are always constexpr. This removes the need for separate declaration/definition checking, which is now gone. - This makes it possible for a constexpr function to be virtual, if they are only dependently virtual. Virtual calls to such functions are not constant expressions. - Likewise, it's now possible for a literal type to have virtual base classes. A constexpr constructor for such a type cannot actually produce a constant expression, though, so add a special-case diagnostic for a constructor call to such a type rather than trying to evaluate it. - Classes with trivial default constructors (for which value initialization can produce a fully-initialized value) are considered literal types. - Classes with volatile members are not literal types. - constexpr constructors can be members of non-literal types. We do not yet use static initialization for global objects constructed in this way. llvm-svn: 150359
* Unrevert r147271, reverted in r147361.Richard Smith2011-12-301-2/+10
| | | | | | | | | | | | Also temporarily remove the assumption from IR gen that we can emit IR for every constant we can fold, since it isn't currently true in C++11, to fix PR11676. Original comment from r147271: constexpr: perform zero-initialization prior to / instead of performing a constructor call when appropriate. Thanks to Eli for spotting this. llvm-svn: 147384
* Revert r147271. This fixes PR11676.Rafael Espindola2011-12-301-10/+2
| | | | llvm-svn: 147362
* constexpr: perform zero-initialization prior to / instead of performing aRichard Smith2011-12-251-2/+10
| | | | | | constructor call when appropriate. Thanks to Eli for spotting this. llvm-svn: 147271
* PR11614: Mark defaulted special constructors as constexpr if their implicitRichard Smith2011-12-221-0/+49
| | | | | | definition would satisfy the constexpr requirements. llvm-svn: 147128
* Compute whether a class is trivial correctly for template classes with an ↵Eli Friedman2011-11-151-2/+9
| | | | | | explicitly deleted or defaulted special member. PR11387. llvm-svn: 144715
* When we notice that a member function is defined with "= delete" or "=Douglas Gregor2011-11-071-10/+4
| | | | | | | | | | | | default", make a note of which is used when creating the initial declaration. Previously, we would wait until later to handle default/delete as a definition, but this is too late: when adding the declaration, we already treated the declaration as "user-provided" when in fact it was merely "user-declared". Fixes PR10861 and PR10442, along with a bunch of FIXMEs. llvm-svn: 144011
* Update all tests other than Driver/std.cpp to use -std=c++11 rather thanRichard Smith2011-10-132-2/+2
| | | | | | -std=c++0x. Patch by Ahmed Charles! llvm-svn: 141900
* Begin work consolidating ShouldDelete* functions.Alexis Hunt2011-10-101-4/+0
| | | | | | | | | | | Begin with just default constructors. One note is that as a side effect of this, a conformance test was removed on the basis that this is almost certainly a defect as with most of union initialization. As it is, clang does not implement union initialization close to the standard as it's quite broken as written. I hope to write a paper addressing the issues eventually. llvm-svn: 141528
* Implement support for C++11 in-class initialization of non-static data members.Richard Smith2011-06-111-0/+173
| | | | llvm-svn: 132878
* Rvalue references for *this: Douglas Gregor2011-01-261-0/+7
| | | | | | | | | | | | - Add ref-qualifiers to the type system; they are part of the canonical type. Print & profile ref-qualifiers - Translate the ref-qualifier from the Declarator chunk for functions to the function type. - Diagnose mis-uses of ref-qualifiers w.r.t. static member functions, free functions, constructors, destructors, etc. - Add serialization and deserialization of ref-qualifiers. llvm-svn: 124281
* Reimplement constructor declarator parsing to cope with template-idsDouglas Gregor2010-01-131-0/+42
that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. llvm-svn: 93322
OpenPOWER on IntegriCloud