summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/member-init.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-191-1/+1
| | | | | | | | | | | | | user interface and documentation, and update __cplusplus for C++20. WG21 considers the C++20 standard to be finished (even though it still has some more steps to pass through in the ISO process). The old flag names are accepted for compatibility, as usual, and we still have lots of references to C++2a in comments and identifiers; those can be cleaned up separately. (cherry picked from commit 24ad121582454e625bdad125c90d9ac0dae948c8)
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initializers. This has some interesting interactions with our existing extensions to support C99 designated initializers as an extension in C++. Those are resolved as follows: * We continue to permit the full breadth of C99 designated initializers in C++, with the exception that we disallow a partial overwrite of an initializer with a non-trivially-destructible type. (Full overwrite is OK, because we won't run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during overload resolution, where they could change the meaning of valid programs. * C++20 disallows reordering of initializers. We only check for that for the simple cases that the C++20 rules permit (designators of the form '.field_name =' and continue to allow reordering in other cases). It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by default in C++20 mode. People are going to learn the C++ rules based on what Clang diagnoses, so it's important we diagnose these properly by default. * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and so still diagnose C99 extensions as described above. We continue to accept designated C++20-compatible initializers in C++ <= 17 silently by default (but naturally still reject under -pedantic-errors). This is not a complete implementation of P0329R4. In particular, that paper introduces new non-C99-compatible syntax { .field { init } }, and we do not support that yet. This is based on a previous patch by Don Hinton, though I've made substantial changes when addressing the above interactions. Differential Revision: https://reviews.llvm.org/D59754 llvm-svn: 370544
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-061-1/+1
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* PR38627: Fix handling of exception specification adjustment forRichard Smith2018-09-051-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-2/+1
| | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+1
| | | | | | | | | | 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
* [Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded ↵Roman Lebedev2018-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | self-assignment (classes) Summary: This has just bit me, so i though it would be nice to avoid that next time :) Motivational case: https://godbolt.org/g/cq9UNk Basically, it's likely to happen if you don't like shadowing issues, and use `-Wshadow` and friends. And it won't be diagnosed by clang. The reason is, these self-assign diagnostics only work for builtin assignment operators. Which makes sense, one could have a very special operator=, that does something unusual in case of self-assignment, so it may make sense to not warn on that. But while it may be intentional in some cases, it may be a bug in other cases, so it would be really great to have some diagnostic about it... Reviewers: aaron.ballman, rsmith, rtrieu, nikola, rjmccall, dblaikie Reviewed By: rjmccall Subscribers: EricWF, lebedev.ri, thakis, Quuxplusone, cfe-commits Differential Revision: https://reviews.llvm.org/D44883 llvm-svn: 329493
* [c++2a] P0683R1: Permit default member initializers for bit-fields.Richard Smith2017-08-281-1/+1
| | | | | | | This would be trivial, except that our in-memory and serialized representations for FieldDecls assumed that this can't happen. llvm-svn: 311867
* PR23135: Don't instantiate constexpr functions referenced in unevaluated ↵Richard Smith2017-01-071-14/+10
| | | | | | | | | | | | | | | | | | | | | operands where possible. This implements something like the current direction of DR1581: we use a narrow syntactic check to determine the set of places where a constant expression could be evaluated, and only instantiate a constexpr function or variable if it's referenced in one of those contexts, or is odr-used. It's not yet clear whether this is the right set of syntactic locations; we currently consider all contexts within templates that would result in odr-uses after instantiation, and contexts within list-initialization (narrowing conversions take another victim...), as requiring instantiation. We could in principle restrict the former cases more (only const integral / reference variable initializers, and contexts in which a constant expression is required, perhaps). However, this is sufficient to allow us to accept libstdc++ code, which relies on GCC's behavior (which appears to be somewhat similar to this approach). llvm-svn: 291318
* Fix the spelling of 'bitfield' in diagnostics to be consistently 'bit-field'.Chandler Carruth2016-12-201-1/+1
| | | | | | | | The latter agrees with most existing diagnostics and the C and C++ standards. Differential Revision: https://reviews.llvm.org/D26530 llvm-svn: 290159
* DR1295 and cleanup for P0135R1: Make our initialization code more directlyRichard Smith2016-12-091-1/+1
| | | | | | | | | | | | | | | mirror the description in the standard. Per DR1295, this means that binding a const / rvalue reference to a bit-field no longer "binds directly", and per P0135R1, this means that we materialize a temporary in reference binding after adjusting cv-qualifiers and before performing a derived-to-base cast. In C++11 onwards, this should have fixed the last case where we would materialize a temporary of the wrong type (with a subobject adjustment inside the MaterializeTemporaryExpr instead of outside), but we still have to deal with that possibility in C++98, unless we want to start using xvalues to represent materialized temporaries there too. llvm-svn: 289250
* Make diagnostic for use of default member initializer before enclosing class isRichard Smith2016-11-221-10/+10
| | | | | | | complete a little more general; it is produced in other cases than the one that it previously talked about. llvm-svn: 287713
* [Sema] Don't crash when a field w/ a mem-initializer clashes with a record nameDavid Majnemer2016-06-091-0/+10
| | | | | | | | | | | It is possible for a field and a class to have the same name. In such cases, performing lookup for the field might return a result set with more than one entry. An overzealous assertion fired, causing us to crash instead of using the non-class lookup result. This fixes PR28060. llvm-svn: 272247
* Sema: Dependent array designators cannot be checkedDavid Majnemer2015-01-091-0/+7
| | | | | | | | | | | We forgot to mark designated initializer expression that contain type dependent array designators as type dependent. This would lead to crashes when we try to determine which array element we were trying to initialize. This fixes PR22056. llvm-svn: 225494
* Handle use of default member initializers before end of outermost classReid Kleckner2014-11-171-1/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
* PR18560: When switching to a new context, don't just save and restore anRichard Smith2014-01-241-0/+10
| | | | | | | override for the type of 'this', also clear it out (unless we're entering the context of a lambda-expression, where it should be inherited). llvm-svn: 199962
* When we're synthesizing copy/move-assignment, we can't form a reference to anEli Friedman2013-06-071-0/+11
| | | | | | invalid field; make sure we don't try. Fixes <rdar://problem/14084171>. llvm-svn: 183479
* PR14838: When a member reference is bound to a temporary, don't forget toRichard Smith2013-01-081-0/+16
| | | | | | | perform the semantic checks associated with the destruction of that temporary. It'll be destroyed at the end of the constructor. llvm-svn: 171818
* Final piece of core issue 1330: delay computing the exception specification ofRichard Smith2012-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Recover properly if a class member declaration starts with a scope specifierRichard Smith2012-05-091-1/+1
| | | | | | or template-id which can't be parsed. llvm-svn: 156468
* Fix crash-on-invalid for 'operator int[]()' in C++11.David Blaikie2012-02-141-0/+3
| | | | | | Signed off by Richard Smith. llvm-svn: 150464
* Update all tests other than Driver/std.cpp to use -std=c++11 rather thanRichard Smith2011-10-131-1/+1
| | | | | | -std=c++0x. Patch by Ahmed Charles! llvm-svn: 141900
* When parsing a function-try-block that does not have aDouglas Gregor2011-09-071-0/+18
| | | | | | | | ctor-initializer, remember to call the Sema action to generate default ctor-initializers. What a delightful little miscompile. Fixes PR10578 / <rdar://problem/9877267>. llvm-svn: 139253
* Don't assert on initialized typedef declarations in classes:Richard Smith2011-06-121-0/+4
| | | | | | | | | | | | struct { typedef int A = 0; }; According to the C++11 standard, this is not ill-formed, but does not have any ascribed meaning. We can't reasonably accept it, so treat it as ill-formed. Also switch C++ from an incorrect 'fields can only be initialized in constructors' diagnostic for this case to C's 'illegal initializer (only variables can be initialized)' llvm-svn: 132890
* Implement support for C++11 in-class initialization of non-static data members.Richard Smith2011-06-111-0/+50
llvm-svn: 132878
OpenPOWER on IntegriCloud