maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/AST/DeclCXX.cpp

2733 lines
106 KiB
C++
Raw Normal View History

[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
//===- DeclCXX.cpp - C++ Declaration AST Node Implementation --------------===//
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file implements the C++ related Decl classes.
//
//===----------------------------------------------------------------------===//
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
#include "clang/AST/DeclCXX.h"
#include "clang/AST/ASTContext.h"
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
#include "clang/AST/ASTLambda.h"
Put the mechanism in place to track modifications in an AST entity that were committed after its initial creation/deserialization and store the changes in a chained PCH. The idea is that the AST entities call methods on the ASTMutationListener to give notifications of changes; the PCHWriter implements the ASTMutationListener interface and stores the incremental changes of the updated entity. WIP llvm-svn: 117235
2010-10-25 01:26:36 +08:00
#include "clang/AST/ASTMutationListener.h"
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
#include "clang/AST/ASTUnresolvedSet.h"
Move the maintenance of CXXRecordDecl::DefinitionData's Abstract bit completely into CXXRecordDecl, by adding a new completeDefinition() function. This required a little reshuffling of the final-overrider checking code, since the "abstract" calculation in the presence of abstract base classes needs to occur in CXXRecordDecl::completeDefinition() but we don't want to compute final overriders more than one in the common case. llvm-svn: 115007
2010-09-29 08:15:42 +08:00
#include "clang/AST/CXXInheritance.h"
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
#include "clang/AST/DeclBase.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "clang/AST/DeclTemplate.h"
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
#include "clang/AST/DeclarationName.h"
More static_assert work. Check that the assert expr is valid and show an error if it's false. Create the declaration and add it to the current context. llvm-svn: 66995
2009-03-14 08:25:26 +08:00
#include "clang/AST/Expr.h"
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
#include "clang/AST/ExprCXX.h"
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
#include "clang/AST/LambdaCapture.h"
#include "clang/AST/NestedNameSpecifier.h"
Add more ODR checking. Add the basics for the ODRHash class, which will only process Decl's from a whitelist, which currently only has AccessSpecDecl. Different access specifiers in merged classes can now be detected. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295800
2017-02-22 09:11:25 +08:00
#include "clang/AST/ODRHash.h"
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
#include "clang/AST/Type.h"
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
#include "clang/AST/TypeLoc.h"
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
#include "clang/AST/UnresolvedSet.h"
#include "clang/Basic/Diagnostic.h"
Don't build identifiers for C++ constructors, destructors, or conversion functions. Instead, we just use a placeholder identifier for these (e.g., "<constructor>") and override NamedDecl::getName() to provide a human-readable name. This is one potential solution to the problem; another solution would be to replace the use of IdentifierInfo* in NamedDecl with a different class that deals with identifiers better. I'm also prototyping that to see how it compares, but this commit is better than what we had previously. llvm-svn: 59193
2008-11-13 07:21:09 +08:00
#include "clang/Basic/IdentifierTable.h"
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
#include "clang/Basic/LLVM.h"
#include "clang/Basic/LangOptions.h"
#include "clang/Basic/OperatorKinds.h"
#include "clang/Basic/PartialDiagnostic.h"
#include "clang/Basic/SourceLocation.h"
#include "clang/Basic/Specifiers.h"
#include "llvm/ADT/None.h"
More improvement in building list of visible conversion functions for a class when needed. llvm-svn: 81624
2009-09-13 03:52:10 +08:00
#include "llvm/ADT/SmallPtrSet.h"
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
#include "llvm/ADT/SmallVector.h"
#include "llvm/ADT/iterator_range.h"
#include "llvm/Support/Casting.h"
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/raw_ostream.h"
#include <algorithm>
#include <cassert>
#include <cstddef>
#include <cstdint>
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
using namespace clang;
//===----------------------------------------------------------------------===//
// Decl Allocation/Deallocation Method Implementations
//===----------------------------------------------------------------------===//
Representation of template type parameters and non-type template parameters, with some semantic analysis: - Template parameters are introduced into template parameter scope - Complain about template parameter shadowing (except in Microsoft mode) Note that we leak template parameter declarations like crazy, a problem we'll remedy once we actually create proper declarations for templates. Next up: dependent types and value-dependent/type-dependent expressions. llvm-svn: 60597
2008-12-06 02:15:24 +08:00
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void AccessSpecDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
AccessSpecDecl *AccessSpecDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
return new (C, ID) AccessSpecDecl(EmptyShell());
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
void LazyASTUnresolvedSet::getFromExternalSource(ASTContext &C) const {
ExternalASTSource *Source = C.getExternalSource();
assert(Impl.Decls.isLazy() && "getFromExternalSource for non-lazy set");
assert(Source && "getFromExternalSource with no external source");
for (ASTUnresolvedSet::iterator I = Impl.begin(); I != Impl.end(); ++I)
I.setDecl(cast<NamedDecl>(Source->GetExternalDecl(
reinterpret_cast<uintptr_t>(I.getDecl()) >> 2)));
Impl.Decls.setLazy(false);
}
Extract a common structure for holding information about the definition of a C++ record. Exposed a lot of problems where various routines were silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order) when presented with a non-definition. Also cuts down on memory usage. llvm-svn: 95330
2010-02-05 06:26:26 +08:00
CXXRecordDecl::DefinitionData::DefinitionData(CXXRecordDecl *D)
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
: UserDeclaredConstructor(false), UserDeclaredSpecialMembers(0),
Aggregate(true), PlainOldData(true), Empty(true), Polymorphic(false),
Abstract(false), IsStandardLayout(true), HasNoNonEmptyBases(true),
HasPrivateFields(false), HasProtectedFields(false),
HasPublicFields(false), HasMutableFields(false), HasVariantMembers(false),
HasOnlyCMembers(true), HasInClassInitializer(false),
HasUninitializedReferenceMember(false), HasUninitializedFields(false),
Add support for derived class special members hiding functions brought in from a base class via a using-declaration. If a class has a using-declaration declaring either a constructor or an assignment operator, eagerly declare its special members in case they need to displace a shadow declaration from a using-declaration. llvm-svn: 269398
2016-05-13 14:47:56 +08:00
HasInheritedConstructor(false), HasInheritedAssignment(false),
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
NeedOverloadResolutionForCopyConstructor(false),
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
NeedOverloadResolutionForMoveConstructor(false),
NeedOverloadResolutionForMoveAssignment(false),
NeedOverloadResolutionForDestructor(false),
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
DefaultedCopyConstructorIsDeleted(false),
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
DefaultedMoveConstructorIsDeleted(false),
DefaultedMoveAssignmentIsDeleted(false),
DefaultedDestructorIsDeleted(false), HasTrivialSpecialMembers(SMF_All),
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
HasTrivialSpecialMembersForCall(SMF_All),
DeclaredNonTrivialSpecialMembers(0),
DeclaredNonTrivialSpecialMembersForCall(0), HasIrrelevantDestructor(true),
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
HasConstexprNonCopyMoveConstructor(false),
Fix rejects-valid caused by r261297. r261297 called hasUserProvidedDefaultConstructor() to check if defining a const object is ok. This is incorrect for this example: struct X { template<typename ...T> X(T...); int n; }; const X x; // formerly OK, now bogus error Instead, track if a class has a defaulted default constructor, and disallow a const object for classes that either have defaulted default constructors or if they need an implicit constructor. Bug report and fix approach by Richard Smith, thanks! llvm-svn: 261770
2016-02-25 04:58:14 +08:00
HasDefaultedDefaultConstructor(false),
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
CanPassInRegisters(true),
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
DefaultedDefaultConstructorIsConstexpr(true),
HasConstexprDefaultConstructor(false),
HasNonLiteralTypeFieldsOrBases(false), ComputedVisibleConversions(false),
UserProvidedDefaultConstructor(false), DeclaredSpecialMembers(0),
C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
2017-02-26 07:53:05 +08:00
ImplicitCopyConstructorCanHaveConstParamForVBase(true),
ImplicitCopyConstructorCanHaveConstParamForNonVBase(true),
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
ImplicitCopyAssignmentHasConstParam(true),
HasDeclaredCopyConstructorWithConstParam(false),
HasDeclaredCopyAssignmentWithConstParam(false), IsLambda(false),
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
IsParsingBaseSpecifiers(false), HasODRHash(false), Definition(D) {}
Extract a common structure for holding information about the definition of a C++ record. Exposed a lot of problems where various routines were silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order) when presented with a non-definition. Also cuts down on memory usage. llvm-svn: 95330
2010-02-05 06:26:26 +08:00
CXXRecordDecl: Split getBases/getVBases into a slow and a fast path. This avoids costly computation of getASTContext() and drops the header dependency from DeclCXX.h to ASTContext.h. llvm-svn: 159716
2012-07-05 01:03:33 +08:00
CXXBaseSpecifier *CXXRecordDecl::DefinitionData::getBasesSlowCase() const {
return Bases.get(Definition->getASTContext().getExternalSource());
}
CXXBaseSpecifier *CXXRecordDecl::DefinitionData::getVBasesSlowCase() const {
return VBases.get(Definition->getASTContext().getExternalSource());
}
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
CXXRecordDecl::CXXRecordDecl(Kind K, TagKind TK, const ASTContext &C,
DeclContext *DC, SourceLocation StartLoc,
SourceLocation IdLoc, IdentifierInfo *Id,
CXXRecordDecl *PrevDecl)
: RecordDecl(K, TK, C, DC, StartLoc, IdLoc, Id, PrevDecl),
DefinitionData(PrevDecl ? PrevDecl->DefinitionData
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
: nullptr) {}
Don't build identifiers for C++ constructors, destructors, or conversion functions. Instead, we just use a placeholder identifier for these (e.g., "<constructor>") and override NamedDecl::getName() to provide a human-readable name. This is one potential solution to the problem; another solution would be to replace the use of IdentifierInfo* in NamedDecl with a different class that deals with identifiers better. I'm also prototyping that to see how it compares, but this commit is better than what we had previously. llvm-svn: 59193
2008-11-13 07:21:09 +08:00
PR3558: mark "logically const" accessor methods in ASTContext as const, and mark the fields they use as mutable. This allows us to remove a few const_casts. llvm-svn: 123314
2011-01-12 17:06:06 +08:00
CXXRecordDecl *CXXRecordDecl::Create(const ASTContext &C, TagKind TK,
Fixed InnerLocStart. llvm-svn: 127330
2011-03-09 22:09:51 +08:00
DeclContext *DC, SourceLocation StartLoc,
SourceLocation IdLoc, IdentifierInfo *Id,
[Modules TS] Module ownership semantics for redeclarations. When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. This reinstates r315251 and r315256, reverted in r315309 and r315308 respectively, tweaked to avoid triggering a linkage calculation when declaring implicit special members (this exposed our pre-existing issue with typedef names for linkage changing the linkage of types whose linkage has already been computed and cached in more cases). A testcase for that regression has been added in r315366. llvm-svn: 315379
2017-10-11 06:33:17 +08:00
CXXRecordDecl *PrevDecl,
Make sure that the type associated with a class template is dependent. llvm-svn: 71878
2009-05-16 03:11:46 +08:00
bool DelayTypeCreation) {
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
CXXRecordDecl *R = new (C, DC) CXXRecordDecl(CXXRecord, TK, C, DC, StartLoc,
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
IdLoc, Id, PrevDecl);
Ensure that type definitions present in just-loaded modules are visible. The basic problem here is that a given translation unit can use forward declarations to form pointers to a given type, say, class X; X *x; and then import a module that includes a definition of X: import XDef; We will then fail when attempting to access a member of X, e.g., x->method() because the AST reader did not know to look for a default of a class named X within the new module. This implementation is a bit of a C-centric hack, because the only definitions that can have this property are enums, structs, unions, Objective-C classes, and Objective-C protocols, and all of those are either visible at the top-level or can't be defined later. Hence, we can use the out-of-date-ness of the name and the identifier-update mechanism to force the update. In C++, we will not be so lucky, and will need a more advanced solution, because the definitions could be in namespaces defined in two different modules, e.g., // module 1 namespace N { struct X; } // module 2 namespace N { struct X { /* ... */ }; } One possible implementation here is for C++ to extend the information associated with each identifier table to include the declaration IDs of any definitions associated with that name, regardless of context. We would have to eagerly load those definitions. llvm-svn: 174794
2013-02-09 09:35:03 +08:00
R->MayHaveOutOfDateDef = C.getLangOpts().Modules;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Make tag declarations redeclarable. This change has three purposes: 1) Allow the Index library (and any other interested client) to walk the set of declarations for a given tag (enum, union, class, whatever). At the moment, this information is not readily available. 2) Reduce our dependence on TagDecl::TypeForDecl being mapped down to a TagType (for which getDecl() will return the tag definition, if one exists). This property won't exist for class template partial specializations. 3) Make the canonical declaration of a TagDecl actually canonical, e.g., so that it does not change when the tag is defined. llvm-svn: 77523
2009-07-30 07:36:44 +08:00
// FIXME: DelayTypeCreation seems like such a hack
Make sure that the type associated with a class template is dependent. llvm-svn: 71878
2009-05-16 03:11:46 +08:00
if (!DelayTypeCreation)
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
C.getTypeDeclType(R, PrevDecl);
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
return R;
}
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
CXXRecordDecl *
CXXRecordDecl::CreateLambda(const ASTContext &C, DeclContext *DC,
TypeSourceInfo *Info, SourceLocation Loc,
bool Dependent, bool IsGeneric,
LambdaCaptureDefault CaptureDefault) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
CXXRecordDecl *R =
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
new (C, DC) CXXRecordDecl(CXXRecord, TTK_Class, C, DC, Loc, Loc,
nullptr, nullptr);
Move the storage of lambda captures and capture initializers from LambdaExpr over to the CXXRecordDecl. This allows us to eliminate the back-link from the closure type to the LambdaExpr, which will simplify and lazify AST deserialization. llvm-svn: 150393
2012-02-13 23:44:47 +08:00
R->IsBeingDefined = true;
Avoid allocating extra memory to handle the lazy definition data pointer for CXXRecordDecls when modules is enabled. llvm-svn: 209482
2014-05-23 07:19:02 +08:00
R->DefinitionData =
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
new (C) struct LambdaDefinitionData(R, Info, Dependent, IsGeneric,
Avoid allocating extra memory to handle the lazy definition data pointer for CXXRecordDecls when modules is enabled. llvm-svn: 209482
2014-05-23 07:19:02 +08:00
CaptureDefault);
Ensure that type definitions present in just-loaded modules are visible. The basic problem here is that a given translation unit can use forward declarations to form pointers to a given type, say, class X; X *x; and then import a module that includes a definition of X: import XDef; We will then fail when attempting to access a member of X, e.g., x->method() because the AST reader did not know to look for a default of a class named X within the new module. This implementation is a bit of a C-centric hack, because the only definitions that can have this property are enums, structs, unions, Objective-C classes, and Objective-C protocols, and all of those are either visible at the top-level or can't be defined later. Hence, we can use the out-of-date-ness of the name and the identifier-update mechanism to force the update. In C++, we will not be so lucky, and will need a more advanced solution, because the definitions could be in namespaces defined in two different modules, e.g., // module 1 namespace N { struct X; } // module 2 namespace N { struct X { /* ... */ }; } One possible implementation here is for C++ to extend the information associated with each identifier table to include the declaration IDs of any definitions associated with that name, regardless of context. We would have to eagerly load those definitions. llvm-svn: 174794
2013-02-09 09:35:03 +08:00
R->MayHaveOutOfDateDef = false;
Mark lambda closure classes as being implicitly-generated. Summary: Closure classes for C++ lambdas are always compiler-generated. This one-line change calls setImplicit(true) on them at creation time, such that a default RecursiveASTVisitor (or any for which shouldVisitImplicitCode returns false) will skip them. Reviewers: rsmith, dblaikie Reviewed By: dblaikie CC: klimek, revane, cfe-commits, jordan_rose Differential Revision: http://llvm-reviews.chandlerc.com/D1593 llvm-svn: 190073
2013-09-06 01:46:21 +08:00
R->setImplicit(true);
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
C.getTypeDeclType(R, /*PrevDecl=*/nullptr);
Move the storage of lambda captures and capture initializers from LambdaExpr over to the CXXRecordDecl. This allows us to eliminate the back-link from the closure type to the LambdaExpr, which will simplify and lazify AST deserialization. llvm-svn: 150393
2012-02-13 23:44:47 +08:00
return R;
}
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
CXXRecordDecl *
CXXRecordDecl::CreateDeserialized(const ASTContext &C, unsigned ID) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
CXXRecordDecl *R = new (C, ID) CXXRecordDecl(
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
CXXRecord, TTK_Struct, C, nullptr, SourceLocation(), SourceLocation(),
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
nullptr, nullptr);
Ensure that type definitions present in just-loaded modules are visible. The basic problem here is that a given translation unit can use forward declarations to form pointers to a given type, say, class X; X *x; and then import a module that includes a definition of X: import XDef; We will then fail when attempting to access a member of X, e.g., x->method() because the AST reader did not know to look for a default of a class named X within the new module. This implementation is a bit of a C-centric hack, because the only definitions that can have this property are enums, structs, unions, Objective-C classes, and Objective-C protocols, and all of those are either visible at the top-level or can't be defined later. Hence, we can use the out-of-date-ness of the name and the identifier-update mechanism to force the update. In C++, we will not be so lucky, and will need a more advanced solution, because the definitions could be in namespaces defined in two different modules, e.g., // module 1 namespace N { struct X; } // module 2 namespace N { struct X { /* ... */ }; } One possible implementation here is for C++ to extend the information associated with each identifier table to include the declaration IDs of any definitions associated with that name, regardless of context. We would have to eagerly load those definitions. llvm-svn: 174794
2013-02-09 09:35:03 +08:00
R->MayHaveOutOfDateDef = false;
return R;
Add some side-effect free Create methods for TypeDecl subclasses and use them for PCH reading. llvm-svn: 107468
2010-07-02 19:54:55 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
void
Revert r256399 "[Sema] ArrayRef-ize ActOnBaseSpecifiers. NFC" It broke lldb build. llvm-svn: 256403
2015-12-25 08:36:02 +08:00
CXXRecordDecl::setBases(CXXBaseSpecifier const * const *Bases,
unsigned NumBases) {
Remove another redundant ASTContext parameter llvm-svn: 95843
2010-02-11 09:30:34 +08:00
ASTContext &C = getASTContext();
Keep track of whether a C++ class is an aggregate. Don't allow initialization of non-aggregates with initializer lists. llvm-svn: 58757
2008-11-06 00:20:31 +08:00
Make the deserialization of C++ base class specifiers lazy, improving the performance of C++ PCH and reducing stack depth in the reader. llvm-svn: 117732
2010-10-30 06:39:52 +08:00
if (!data().Bases.isOffset() && data().NumBases > 0)
C.Deallocate(data().getBases());
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Revert r256399 "[Sema] ArrayRef-ize ActOnBaseSpecifiers. NFC" It broke lldb build. llvm-svn: 256403
2015-12-25 08:36:02 +08:00
if (NumBases) {
Now that C++17 is official (https://www.iso.org/standard/68564.html), start changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
2017-12-05 04:27:34 +08:00
if (!C.getLangOpts().CPlusPlus17) {
P0017R1: In C++1z, an aggregate class can have (public non-virtual) base classes; these are initialized as if they were data members. llvm-svn: 262963
2016-03-09 06:17:41 +08:00
// C++ [dcl.init.aggr]p1:
// An aggregate is [...] a class with [...] no base classes [...].
data().Aggregate = false;
}
Simplify RecordDeclCXX::setBases slightly. No functional change. Add test that a variadic base list which expands to 0 bases doesn't make the class a non-aggregate. This test passed before the change, too. llvm-svn: 142411
2011-10-19 04:08:55 +08:00
// C++ [class]p4:
// A POD-struct is an aggregate class...
data().PlainOldData = false;
}
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
// The set of seen virtual base types.
When collecting virtual bases it's very important to use the canonical type of the base class. Otherwise, we might add the same virtual base class twice if the virtual base is an instantiated template. Fixes PR6251. llvm-svn: 99829
2010-03-30 03:49:09 +08:00
llvm::SmallPtrSet<CanQualType, 8> SeenVBaseTypes;
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
// The virtual bases of this class.
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<const CXXBaseSpecifier *, 8> VBases;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Revert r256399 "[Sema] ArrayRef-ize ActOnBaseSpecifiers. NFC" It broke lldb build. llvm-svn: 256403
2015-12-25 08:36:02 +08:00
data().Bases = new(C) CXXBaseSpecifier [NumBases];
data().NumBases = NumBases;
for (unsigned i = 0; i < NumBases; ++i) {
Make the deserialization of C++ base class specifiers lazy, improving the performance of C++ PCH and reducing stack depth in the reader. llvm-svn: 117732
2010-10-30 06:39:52 +08:00
data().getBases()[i] = *Bases[i];
Patch to build list of inherited virtual base classes in their order of construction for each class and use it to to check on propery order of base class construction under -Wreorder option. llvm-svn: 75270
2009-07-11 04:13:23 +08:00
// Keep track of inherited vbases for this base class.
const CXXBaseSpecifier *Base = Bases[i];
QualType BaseType = Base->getType();
Skip dependent virtual base classes; fixes PR6413. llvm-svn: 97291
2010-02-27 08:25:28 +08:00
// Skip dependent types; we can't do any checking on them now.
Patch to build list of inherited virtual base classes in their order of construction for each class and use it to to check on propery order of base class construction under -Wreorder option. llvm-svn: 75270
2009-07-11 04:13:23 +08:00
if (BaseType->isDependentType())
continue;
CXXRecordDecl *BaseClassDecl
Change uses of: Type::getAsReferenceType() -> Type::getAs<ReferenceType>() Type::getAsRecordType() -> Type::getAs<RecordType>() Type::getAsPointerType() -> Type::getAs<PointerType>() Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>() Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>() Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>() Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>() Type::getAsReferenceType() -> Type::getAs<ReferenceType>() Type::getAsTagType() -> Type::getAs<TagType>() And remove Type::getAsReferenceType(), etc. This change is similar to one I made a couple weeks ago, but that was partly reverted pending some additional design discussion. With Doug's pending smart pointer changes for Types, it seemed natural to take this approach. llvm-svn: 77510
2009-07-30 05:53:49 +08:00
= cast<CXXRecordDecl>(BaseType->getAs<RecordType>()->getDecl());
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
if (!BaseClassDecl->isEmpty()) {
if (!data().Empty) {
// C++0x [class]p7:
// A standard-layout class is a class that:
// [...]
// -- either has no non-static data members in the most derived
// class and at most one base class with non-static data members,
// or has no base classes with non-static data members, and
// If this is the second non-empty base, then neither of these two
// clauses can be true.
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
data().IsStandardLayout = false;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
}
[AST] Cleanup comments regarding CXXRecordDecl::isEmpty We were missing references to the standard, some of our home-grown verbiage didn't make any sense. No functional change is intended. llvm-svn: 270353
2016-05-22 13:34:26 +08:00
// C++14 [meta.unary.prop]p4:
// T is a class type [...] with [...] no base class B for which
// is_empty<B>::value is false.
Centralize the management of CXXRecordDecl::DefinitionData's Empty bit in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>. This reinstates r114924, with one crucial bug fix: we were ignoring the implicit fields created by anonymous structs/unions when updating the bits in CXXRecordDecl, which means that a class/struct containing only an anonymous class/struct would be considered "empty". Hilarity follows. llvm-svn: 114980
2010-09-29 04:38:10 +08:00
data().Empty = false;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
data().HasNoNonEmptyBases = false;
}
Centralize the management of CXXRecordDecl::DefinitionData's Empty bit in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>. This reinstates r114924, with one crucial bug fix: we were ignoring the implicit fields created by anonymous structs/unions when updating the bits in CXXRecordDecl, which means that a class/struct containing only an anonymous class/struct would be considered "empty". Hilarity follows. llvm-svn: 114980
2010-09-29 04:38:10 +08:00
P0017R1: In C++1z, an aggregate class can have (public non-virtual) base classes; these are initialized as if they were data members. llvm-svn: 262963
2016-03-09 06:17:41 +08:00
// C++1z [dcl.init.agg]p1:
// An aggregate is a class with [...] no private or protected base classes
if (Base->getAccessSpecifier() != AS_public)
data().Aggregate = false;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
// C++ [class.virtual]p1:
// A class that declares or inherits a virtual function is called a
// polymorphic class.
if (BaseClassDecl->isPolymorphic())
data().Polymorphic = true;
Implement most of the remaining logic in __is_literal type trait. This should now support all of the C++98 types, and all of the C++0x types Clang supports. llvm-svn: 130079
2011-04-24 10:49:34 +08:00
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// C++0x [class]p7:
// A standard-layout class is a class that: [...]
// -- has no non-standard-layout base classes
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
if (!BaseClassDecl->isStandardLayout())
data().IsStandardLayout = false;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
Implement most of the remaining logic in __is_literal type trait. This should now support all of the C++98 types, and all of the C++0x types Clang supports. llvm-svn: 130079
2011-04-24 10:49:34 +08:00
// Record if this base is the first non-literal field or base.
C++1y constexpr extensions, round 1: Allow most forms of declaration and 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
2013-04-22 23:31:51 +08:00
if (!hasNonLiteralTypeFieldsOrBases() && !BaseType->isLiteralType(C))
Implement most of the remaining logic in __is_literal type trait. This should now support all of the C++98 types, and all of the C++0x types Clang supports. llvm-svn: 130079
2011-04-24 10:49:34 +08:00
data().HasNonLiteralTypeFieldsOrBases = true;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
// Now go through all virtual bases of this base and add them.
[C++11] Replacing CXXRecordDecl iterators vbases_begin() and vbases_end() with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203808
2014-03-14 00:15:17 +08:00
for (const auto &VBase : BaseClassDecl->vbases()) {
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
// Add this base if it's not already in the list.
Update for LLVM API change to make Small(Ptr)Set::insert return pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
2014-11-19 15:49:47 +08:00
if (SeenVBaseTypes.insert(C.getCanonicalType(VBase.getType())).second) {
[C++11] Replacing CXXRecordDecl iterators vbases_begin() and vbases_end() with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203808
2014-03-14 00:15:17 +08:00
VBases.push_back(&VBase);
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// C++11 [class.copy]p8:
// The implicitly-declared copy constructor for a class X will have
// the form 'X::X(const X&)' if each [...] virtual base class B of X
// has a copy constructor whose first parameter is of type
// 'const B&' or 'const volatile B&' [...]
[C++11] Replacing CXXRecordDecl iterators vbases_begin() and vbases_end() with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203808
2014-03-14 00:15:17 +08:00
if (CXXRecordDecl *VBaseDecl = VBase.getType()->getAsCXXRecordDecl())
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
if (!VBaseDecl->hasCopyConstructorWithConstParam())
C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
2017-02-26 07:53:05 +08:00
data().ImplicitCopyConstructorCanHaveConstParamForVBase = false;
P0017R1: In C++1z, an aggregate class can have (public non-virtual) base classes; these are initialized as if they were data members. llvm-svn: 262963
2016-03-09 06:17:41 +08:00
// C++1z [dcl.init.agg]p1:
// An aggregate is a class with [...] no virtual base classes
data().Aggregate = false;
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
}
Patch to build list of inherited virtual base classes in their order of construction for each class and use it to to check on propery order of base class construction under -Wreorder option. llvm-svn: 75270
2009-07-11 04:13:23 +08:00
}
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
if (Base->isVirtual()) {
// Add this base if it's not already in the list.
Update for LLVM API change to make Small(Ptr)Set::insert return pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
2014-11-19 15:49:47 +08:00
if (SeenVBaseTypes.insert(C.getCanonicalType(BaseType)).second)
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
VBases.push_back(Base);
[AST] Cleanup comments regarding CXXRecordDecl::isEmpty We were missing references to the standard, some of our home-grown verbiage didn't make any sense. No functional change is intended. llvm-svn: 270353
2016-05-22 13:34:26 +08:00
// C++14 [meta.unary.prop] is_empty:
// T is a class type, but not a union type, with ... no virtual base
// classes
Centralize the management of CXXRecordDecl::DefinitionData's Empty bit in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>. This reinstates r114924, with one crucial bug fix: we were ignoring the implicit fields created by anonymous structs/unions when updating the bits in CXXRecordDecl, which means that a class/struct containing only an anonymous class/struct would be considered "empty". Hilarity follows. llvm-svn: 114980
2010-09-29 04:38:10 +08:00
data().Empty = false;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
P0017R1: In C++1z, an aggregate class can have (public non-virtual) base classes; these are initialized as if they were data members. llvm-svn: 262963
2016-03-09 06:17:41 +08:00
// C++1z [dcl.init.agg]p1:
// An aggregate is a class with [...] no virtual base classes
data().Aggregate = false;
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
// C++11 [class.ctor]p5, C++11 [class.copy]p12, C++11 [class.copy]p25:
// A [default constructor, copy/move constructor, or copy/move assignment
// operator for a class X] is trivial [...] if:
// -- class X has [...] no virtual base classes
data().HasTrivialSpecialMembers &= SMF_Destructor;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
data().HasTrivialSpecialMembersForCall &= SMF_Destructor;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// C++0x [class]p7:
// A standard-layout class is a class that: [...]
// -- has [...] no virtual base classes
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
data().IsStandardLayout = false;
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
// C++11 [dcl.constexpr]p4:
// In the definition of a constexpr constructor [...]
// -- the class shall not have any virtual base classes
data().DefaultedDefaultConstructorIsConstexpr = false;
C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
2017-02-26 07:53:05 +08:00
// C++1z [class.copy]p8:
// The implicitly-declared copy constructor for a class X will have
// the form 'X::X(const X&)' if each potentially constructed subobject
// has a copy constructor whose first parameter is of type
// 'const B&' or 'const volatile B&' [...]
if (!BaseClassDecl->hasCopyConstructorWithConstParam())
data().ImplicitCopyConstructorCanHaveConstParamForVBase = false;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
} else {
// C++ [class.ctor]p5:
Rename "hasTrivialConstructor" to "hasTrivialDefaultConstructor" and modify the semantics slightly to accomodate default constructors (I hope). llvm-svn: 131087
2011-05-10 02:22:59 +08:00
// A default constructor is trivial [...] if:
// -- all the direct base classes of its class have trivial default
// constructors.
if (!BaseClassDecl->hasTrivialDefaultConstructor())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_DefaultConstructor;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
// C++0x [class.copy]p13:
// A copy/move constructor for class X is trivial if [...]
// [...]
// -- the constructor selected to copy/move each direct base class
// subobject is trivial, and
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
if (!BaseClassDecl->hasTrivialCopyConstructor())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_CopyConstructor;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
if (!BaseClassDecl->hasTrivialCopyConstructorForCall())
data().HasTrivialSpecialMembersForCall &= ~SMF_CopyConstructor;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
// If the base class doesn't have a simple move constructor, we'll eagerly
// declare it and perform overload resolution to determine which function
// it actually calls. If it does have a simple move constructor, this
// check is correct.
A step towards sorting out handling of triviality of special members in C++11. Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
2012-11-16 08:53:38 +08:00
if (!BaseClassDecl->hasTrivialMoveConstructor())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_MoveConstructor;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
if (!BaseClassDecl->hasTrivialMoveConstructorForCall())
data().HasTrivialSpecialMembersForCall &= ~SMF_MoveConstructor;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
// C++0x [class.copy]p27:
// A copy/move assignment operator for class X is trivial if [...]
// [...]
// -- the assignment operator selected to copy/move each direct base
// class subobject is trivial, and
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
if (!BaseClassDecl->hasTrivialCopyAssignment())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_CopyAssignment;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
// If the base class doesn't have a simple move assignment, we'll eagerly
// declare it and perform overload resolution to determine which function
// it actually calls. If it does have a simple move assignment, this
// check is correct.
A step towards sorting out handling of triviality of special members in C++11. Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
2012-11-16 08:53:38 +08:00
if (!BaseClassDecl->hasTrivialMoveAssignment())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_MoveAssignment;
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
// C++11 [class.ctor]p6:
constexpr: fix typo resulting in move constructors sometimes not being implicitly marked constexpr when they should be. llvm-svn: 147955
2012-01-12 02:26:05 +08:00
// If that user-written default constructor would satisfy the
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
// requirements of a constexpr constructor, the implicitly-defined
// default constructor is constexpr.
if (!BaseClassDecl->hasConstexprDefaultConstructor())
data().DefaultedDefaultConstructorIsConstexpr = false;
C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
2017-02-26 07:53:05 +08:00
// C++1z [class.copy]p8:
// The implicitly-declared copy constructor for a class X will have
// the form 'X::X(const X&)' if each potentially constructed subobject
// has a copy constructor whose first parameter is of type
// 'const B&' or 'const volatile B&' [...]
if (!BaseClassDecl->hasCopyConstructorWithConstParam())
data().ImplicitCopyConstructorCanHaveConstParamForNonVBase = false;
Patch to build list of inherited virtual base classes in their order of construction for each class and use it to to check on propery order of base class construction under -Wreorder option. llvm-svn: 75270
2009-07-11 04:13:23 +08:00
}
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
// C++ [class.ctor]p3:
// A destructor is trivial if all the direct base classes of its class
// have trivial destructors.
if (!BaseClassDecl->hasTrivialDestructor())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_Destructor;
Teach CXXRecordDecl::hasIrrelevantDestructor to check the base classes and data members for deleted or user-provided destructors. Now it's computed in advance, serialize it, and in passing fix all the other record DefinitionData flags whose serialization was missing. llvm-svn: 151441
2012-02-25 15:33:38 +08:00
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
if (!BaseClassDecl->hasTrivialDestructorForCall())
data().HasTrivialSpecialMembersForCall &= ~SMF_Destructor;
Teach CXXRecordDecl::hasIrrelevantDestructor to check the base classes and data members for deleted or user-provided destructors. Now it's computed in advance, serialize it, and in passing fix all the other record DefinitionData flags whose serialization was missing. llvm-svn: 151441
2012-02-25 15:33:38 +08:00
if (!BaseClassDecl->hasIrrelevantDestructor())
data().HasIrrelevantDestructor = false;
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// C++11 [class.copy]p18:
// The implicitly-declared copy assignment oeprator for a class X will
// have the form 'X& X::operator=(const X&)' if each direct base class B
// of X has a copy assignment operator whose parameter is of type 'const
// B&', 'const volatile B&', or 'B' [...]
if (!BaseClassDecl->hasCopyAssignmentWithConstParam())
data().ImplicitCopyAssignmentHasConstParam = false;
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
// A class has an Objective-C object member if... or any of its bases
// has an Objective-C object member.
if (BaseClassDecl->hasObjectMember())
setHasObjectMember(true);
patch for PR9027 and // rdar://11861085 Title: [PR9027] volatile struct bug: member is not loaded at -O; This is caused by last flag passed to @llvm.memcpy being false, not honoring that aggregate has at least one 'volatile' data member (even though aggregate itself has not been qualified as 'volatile'. As a result, optimization optimizes away the memcpy altogether. Patch review by John MaCall (I still need to fix up a test though). llvm-svn: 173535
2013-01-26 07:57:05 +08:00
if (BaseClassDecl->hasVolatileMember())
setHasVolatileMember(true);
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
When determining whether we can make a declaration into a global constant, also consider whether it's a class type that has any mutable fields. If so, it can't be a global constant. llvm-svn: 131276
2011-05-13 09:05:07 +08:00
// Keep track of the presence of mutable fields.
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
if (BaseClassDecl->hasMutableFields()) {
When determining whether we can make a declaration into a global constant, also consider whether it's a class type that has any mutable fields. If so, it can't be a global constant. llvm-svn: 131276
2011-05-13 09:05:07 +08:00
data().HasMutableFields = true;
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
data().NeedOverloadResolutionForCopyConstructor = true;
}
Implement C++03 [dcl.init]p5's checking for value-initialization of references properly, rather than faking it up by pretending that a reference member makes the default constructor non-trivial. That leads to rejects-valids when putting such types inside unions. llvm-svn: 169662
2012-12-08 10:01:17 +08:00
if (BaseClassDecl->hasUninitializedReferenceMember())
data().HasUninitializedReferenceMember = true;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
if (!BaseClassDecl->allowConstDefaultInit())
data().HasUninitializedFields = true;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
addedClassSubobject(BaseClassDecl);
Patch to build list of inherited virtual base classes in their order of construction for each class and use it to to check on propery order of base class construction under -Wreorder option. llvm-svn: 75270
2009-07-11 04:13:23 +08:00
}
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
MS ABI: Fix inheritance model calculation in CRTP CRTP-like patterns involve a class which inherits from another class using itself as a template parameter. However, the base class itself may try to create a pointer-to-member which involves the derived class. This is problematic because we may not have finished parsing the most derived classes' base specifiers yet. It turns out that MSVC simply uses the unspecified inheritance model instead of doing anything fancy. This fixes PR19987. llvm-svn: 210886
2014-06-13 14:43:46 +08:00
if (VBases.empty()) {
data().IsParsingBaseSpecifiers = false;
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
return;
MS ABI: Fix inheritance model calculation in CRTP CRTP-like patterns involve a class which inherits from another class using itself as a template parameter. However, the base class itself may try to create a pointer-to-member which involves the derived class. This is problematic because we may not have finished parsing the most derived classes' base specifiers yet. It turns out that MSVC simply uses the unspecified inheritance model instead of doing anything fancy. This fixes PR19987. llvm-svn: 210886
2014-06-13 14:43:46 +08:00
}
Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order. llvm-svn: 99806
2010-03-29 13:13:12 +08:00
// Create base specifier for any direct or indirect virtual bases.
data().VBases = new (C) CXXBaseSpecifier[VBases.size()];
data().NumVBases = VBases.size();
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
for (int I = 0, E = VBases.size(); I != E; ++I) {
QualType Type = VBases[I]->getType();
if (!Type->isDependentType())
addedClassSubobject(Type->getAsCXXRecordDecl());
Correctly set up the list of virtual base classes for a CXXRecordDecl. Previously we got the source range wrong for everything in the virtual bases list. llvm-svn: 135011
2011-07-13 07:49:11 +08:00
data().getVBases()[I] = *VBases[I];
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
}
MS ABI: Fix inheritance model calculation in CRTP CRTP-like patterns involve a class which inherits from another class using itself as a template parameter. However, the base class itself may try to create a pointer-to-member which involves the derived class. This is problematic because we may not have finished parsing the most derived classes' base specifiers yet. It turns out that MSVC simply uses the unspecified inheritance model instead of doing anything fancy. This fixes PR19987. llvm-svn: 210886
2014-06-13 14:43:46 +08:00
data().IsParsingBaseSpecifiers = false;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
}
[ODRHash] Improve handling of hash values Calculating the hash in Sema::ActOnTagFinishDefinition could happen before all sub-Decls were parsed or processed, which would produce the wrong hash value. Change to calculating the hash on the first use and storing the value instead. Also, avoid using the macros that were only for Boolean fields and use an explicit checker during the DefintionData merge. No functional change, but was this blocking other ODRHash patches. llvm-svn: 299989
2017-04-12 05:31:00 +08:00
unsigned CXXRecordDecl::getODRHash() const {
assert(hasDefinition() && "ODRHash only for records with definitions");
Add more ODR checking. Add the basics for the ODRHash class, which will only process Decl's from a whitelist, which currently only has AccessSpecDecl. Different access specifiers in merged classes can now be detected. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295800
2017-02-22 09:11:25 +08:00
[ODRHash] Improve handling of hash values Calculating the hash in Sema::ActOnTagFinishDefinition could happen before all sub-Decls were parsed or processed, which would produce the wrong hash value. Change to calculating the hash on the first use and storing the value instead. Also, avoid using the macros that were only for Boolean fields and use an explicit checker during the DefintionData merge. No functional change, but was this blocking other ODRHash patches. llvm-svn: 299989
2017-04-12 05:31:00 +08:00
// Previously calculated hash is stored in DefinitionData.
if (DefinitionData->HasODRHash)
return DefinitionData->ODRHash;
Add more ODR checking. Add the basics for the ODRHash class, which will only process Decl's from a whitelist, which currently only has AccessSpecDecl. Different access specifiers in merged classes can now be detected. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295800
2017-02-22 09:11:25 +08:00
[ODRHash] Improve handling of hash values Calculating the hash in Sema::ActOnTagFinishDefinition could happen before all sub-Decls were parsed or processed, which would produce the wrong hash value. Change to calculating the hash on the first use and storing the value instead. Also, avoid using the macros that were only for Boolean fields and use an explicit checker during the DefintionData merge. No functional change, but was this blocking other ODRHash patches. llvm-svn: 299989
2017-04-12 05:31:00 +08:00
// Only calculate hash on first call of getODRHash per record.
ODRHash Hash;
Hash.AddCXXRecordDecl(getDefinition());
DefinitionData->HasODRHash = true;
Add more ODR checking. Add the basics for the ODRHash class, which will only process Decl's from a whitelist, which currently only has AccessSpecDecl. Different access specifiers in merged classes can now be detected. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295800
2017-02-22 09:11:25 +08:00
DefinitionData->ODRHash = Hash.CalculateHash();
[ODRHash] Improve handling of hash values Calculating the hash in Sema::ActOnTagFinishDefinition could happen before all sub-Decls were parsed or processed, which would produce the wrong hash value. Change to calculating the hash on the first use and storing the value instead. Also, avoid using the macros that were only for Boolean fields and use an explicit checker during the DefintionData merge. No functional change, but was this blocking other ODRHash patches. llvm-svn: 299989
2017-04-12 05:31:00 +08:00
return DefinitionData->ODRHash;
Add more ODR checking. Add the basics for the ODRHash class, which will only process Decl's from a whitelist, which currently only has AccessSpecDecl. Different access specifiers in merged classes can now be detected. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295800
2017-02-22 09:11:25 +08:00
}
Part of adding an improved ODR checker. Reserve a spot for ODR hash in CXXRecordDecl and in its modules storage. Default the hash value to 0 for all classes. Differential Revision: https://reviews.llvm.org/D21675 llvm-svn: 295533
2017-02-18 10:09:28 +08:00
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
void CXXRecordDecl::addedClassSubobject(CXXRecordDecl *Subobj) {
// C++11 [class.copy]p11:
// A defaulted copy/move constructor for a class X is defined as
// deleted if X has:
// -- a direct or virtual base class B that cannot be copied/moved [...]
// -- a non-static data member of class type M (or array thereof)
// that cannot be copied or moved [...]
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
if (!Subobj->hasSimpleCopyConstructor())
data().NeedOverloadResolutionForCopyConstructor = true;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
if (!Subobj->hasSimpleMoveConstructor())
data().NeedOverloadResolutionForMoveConstructor = true;
// C++11 [class.copy]p23:
// A defaulted copy/move assignment operator for a class X is defined as
// deleted if X has:
// -- a direct or virtual base class B that cannot be copied/moved [...]
// -- a non-static data member of class type M (or array thereof)
// that cannot be copied or moved [...]
if (!Subobj->hasSimpleMoveAssignment())
data().NeedOverloadResolutionForMoveAssignment = true;
// C++11 [class.ctor]p5, C++11 [class.copy]p11, C++11 [class.dtor]p5:
// A defaulted [ctor or dtor] for a class X is defined as
// deleted if X has:
// -- any direct or virtual base class [...] has a type with a destructor
// that is deleted or inaccessible from the defaulted [ctor or dtor].
// -- any non-static data member has a type with a destructor
// that is deleted or inaccessible from the defaulted [ctor or dtor].
if (!Subobj->hasSimpleDestructor()) {
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
data().NeedOverloadResolutionForCopyConstructor = true;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
data().NeedOverloadResolutionForMoveConstructor = true;
data().NeedOverloadResolutionForDestructor = true;
}
Clean up and document the representation of C++ base classes llvm-svn: 58040
2008-10-24 02:13:27 +08:00
}
When qualified lookup into the current instantiation fails (because it finds nothing), and the current instantiation has dependent base classes, treat the qualified lookup as if it referred to an unknown specialization. Fixes PR6031. llvm-svn: 93433
2010-01-15 01:47:39 +08:00
bool CXXRecordDecl::hasAnyDependentBases() const {
if (!isDependentContext())
return false;
[AST] Turn the callbacks of lookupInBases and forallBases into a function_ref This lets us pass functors (and lambdas) without void * tricks. On the downside we can't pass CXXRecordDecl's Find* members (which are now type safe) to lookupInBases directly, but a lambda trampoline is a small price to pay. No functionality change intended. llvm-svn: 243217
2015-07-25 23:07:25 +08:00
return !forallBases([](const CXXRecordDecl *) { return true; });
When qualified lookup into the current instantiation fails (because it finds nothing), and the current instantiation has dependent base classes, treat the qualified lookup as if it referred to an unknown specialization. Fixes PR6031. llvm-svn: 93433
2010-01-15 01:47:39 +08:00
}
Implement basic __is_trivial type-trait support, enough to close PR9472. This introduces a few APIs on the AST to bundle up the standard-based logic so that programmatic clients have access to exactly the same behavior. There is only one serious FIXME here: checking for non-trivial move constructors and move assignment operators. Those bits need to be added to the declaration and accessors provided. This implementation should be enough for the uses of __is_trivial in libstdc++ 4.6's C++98 library implementation. Ideas for more thorough test cases or any edge cases missing would be appreciated. =D llvm-svn: 130057
2011-04-23 18:47:28 +08:00
bool CXXRecordDecl::isTriviallyCopyable() const {
// C++0x [class]p5:
// A trivially copyable class is a class that:
// -- has no non-trivial copy constructors,
A step towards sorting out handling of triviality of special members in C++11. Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
2012-11-16 08:53:38 +08:00
if (hasNonTrivialCopyConstructor()) return false;
Implement basic __is_trivial type-trait support, enough to close PR9472. This introduces a few APIs on the AST to bundle up the standard-based logic so that programmatic clients have access to exactly the same behavior. There is only one serious FIXME here: checking for non-trivial move constructors and move assignment operators. Those bits need to be added to the declaration and accessors provided. This implementation should be enough for the uses of __is_trivial in libstdc++ 4.6's C++98 library implementation. Ideas for more thorough test cases or any edge cases missing would be appreciated. =D llvm-svn: 130057
2011-04-23 18:47:28 +08:00
// -- has no non-trivial move constructors,
A step towards sorting out handling of triviality of special members in C++11. Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
2012-11-16 08:53:38 +08:00
if (hasNonTrivialMoveConstructor()) return false;
Implement basic __is_trivial type-trait support, enough to close PR9472. This introduces a few APIs on the AST to bundle up the standard-based logic so that programmatic clients have access to exactly the same behavior. There is only one serious FIXME here: checking for non-trivial move constructors and move assignment operators. Those bits need to be added to the declaration and accessors provided. This implementation should be enough for the uses of __is_trivial in libstdc++ 4.6's C++98 library implementation. Ideas for more thorough test cases or any edge cases missing would be appreciated. =D llvm-svn: 130057
2011-04-23 18:47:28 +08:00
// -- has no non-trivial copy assignment operators,
A step towards sorting out handling of triviality of special members in C++11. Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
2012-11-16 08:53:38 +08:00
if (hasNonTrivialCopyAssignment()) return false;
Implement basic __is_trivial type-trait support, enough to close PR9472. This introduces a few APIs on the AST to bundle up the standard-based logic so that programmatic clients have access to exactly the same behavior. There is only one serious FIXME here: checking for non-trivial move constructors and move assignment operators. Those bits need to be added to the declaration and accessors provided. This implementation should be enough for the uses of __is_trivial in libstdc++ 4.6's C++98 library implementation. Ideas for more thorough test cases or any edge cases missing would be appreciated. =D llvm-svn: 130057
2011-04-23 18:47:28 +08:00
// -- has no non-trivial move assignment operators, and
A step towards sorting out handling of triviality of special members in C++11. Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
2012-11-16 08:53:38 +08:00
if (hasNonTrivialMoveAssignment()) return false;
Implement basic __is_trivial type-trait support, enough to close PR9472. This introduces a few APIs on the AST to bundle up the standard-based logic so that programmatic clients have access to exactly the same behavior. There is only one serious FIXME here: checking for non-trivial move constructors and move assignment operators. Those bits need to be added to the declaration and accessors provided. This implementation should be enough for the uses of __is_trivial in libstdc++ 4.6's C++98 library implementation. Ideas for more thorough test cases or any edge cases missing would be appreciated. =D llvm-svn: 130057
2011-04-23 18:47:28 +08:00
// -- has a trivial destructor.
if (!hasTrivialDestructor()) return false;
return true;
}
Teach FunctionDecl::setPure() to (indirectly) mark the Abstract bit in CXXRecordDecl::DefinitionData, rather than having Sema mark the bit. llvm-svn: 114993
2010-09-29 05:55:22 +08:00
void CXXRecordDecl::markedVirtualFunctionPure() {
// C++ [class.abstract]p2:
// A class is abstract if it has at least one pure virtual function.
data().Abstract = true;
}
void CXXRecordDecl::addedMember(Decl *D) {
Normalize line endings of r163013 (part 2). llvm-svn: 163032
2012-09-01 06:18:20 +08:00
if (!D->isImplicit() &&
!isa<FieldDecl>(D) &&
!isa<IndirectFieldDecl>(D) &&
(!isa<TagDecl>(D) || cast<TagDecl>(D)->getTagKind() == TTK_Class ||
cast<TagDecl>(D)->getTagKind() == TTK_Interface))
data().HasOnlyCMembers = false;
// Ignore friends and invalid declarations.
Centralize the handling of CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for copy-assignment operators. Another step toward <rdar://problem/8459981>. llvm-svn: 114899
2010-09-28 06:06:20 +08:00
if (D->getFriendObjectKind() || D->isInvalidDecl())
Clean up the handling of the DeclaredDefaultConstructor and DeclaredCopyConstructor bits in CXXRecordDecl's DefinitionData structure. Rather than having Sema call addedConstructor or set the bits directly at semi-random places, move all of the logic for managing these bits into CXXRecordDecl itself and tie the addedConstructor call into DeclContext::addDecl(). This makes it easier for AST-building clients to get the right bits set in DefinitionData, and is one small part of <rdar://problem/8459981>. llvm-svn: 114889
2010-09-28 05:17:54 +08:00
return;
Centralize the handling of CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for copy-assignment operators. Another step toward <rdar://problem/8459981>. llvm-svn: 114899
2010-09-28 06:06:20 +08:00
FunctionTemplateDecl *FunTmpl = dyn_cast<FunctionTemplateDecl>(D);
if (FunTmpl)
D = FunTmpl->getTemplatedDecl();
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
// FIXME: Pass NamedDecl* to addedMember?
Decl *DUnderlying = D;
if (auto *ND = dyn_cast<NamedDecl>(DUnderlying)) {
DUnderlying = ND->getUnderlyingDecl();
if (FunctionTemplateDecl *UnderlyingFunTmpl =
dyn_cast<FunctionTemplateDecl>(DUnderlying))
DUnderlying = UnderlyingFunTmpl->getTemplatedDecl();
}
Centralize the handling of CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for copy-assignment operators. Another step toward <rdar://problem/8459981>. llvm-svn: 114899
2010-09-28 06:06:20 +08:00
Reinstate r114921, which I've exonerated via a self-host build. Centralize the management of CXXRecordDecl::DefinitionData's Aggregate and PlainOldData bits in CXXRecordDecl itself. Another milepost on the road toward <rdar://problem/8459981>. llvm-svn: 114977
2010-09-29 03:45:33 +08:00
if (CXXMethodDecl *Method = dyn_cast<CXXMethodDecl>(D)) {
if (Method->isVirtual()) {
// C++ [dcl.init.aggr]p1:
// An aggregate is an array or a class with [...] no virtual functions.
data().Aggregate = false;
// C++ [class]p4:
// A POD-struct is an aggregate class...
data().PlainOldData = false;
Centralize the management of CXXRecordDecl::DefinitionData's Empty bit in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>. This reinstates r114924, with one crucial bug fix: we were ignoring the implicit fields created by anonymous structs/unions when updating the bits in CXXRecordDecl, which means that a class/struct containing only an anonymous class/struct would be considered "empty". Hilarity follows. llvm-svn: 114980
2010-09-29 04:38:10 +08:00
[AST] Cleanup comments regarding CXXRecordDecl::isEmpty We were missing references to the standard, some of our home-grown verbiage didn't make any sense. No functional change is intended. llvm-svn: 270353
2016-05-22 13:34:26 +08:00
// C++14 [meta.unary.prop]p4:
// T is a class type [...] with [...] no virtual member functions...
Centralize the management of CXXRecordDecl::DefinitionData's Empty bit in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>. This reinstates r114924, with one crucial bug fix: we were ignoring the implicit fields created by anonymous structs/unions when updating the bits in CXXRecordDecl, which means that a class/struct containing only an anonymous class/struct would be considered "empty". Hilarity follows. llvm-svn: 114980
2010-09-29 04:38:10 +08:00
data().Empty = false;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
// C++ [class.virtual]p1:
// A class that declares or inherits a virtual function is called a
// polymorphic class.
data().Polymorphic = true;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
// C++11 [class.ctor]p5, C++11 [class.copy]p12, C++11 [class.copy]p25:
// A [default constructor, copy/move constructor, or copy/move
// assignment operator for a class X] is trivial [...] if:
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
// -- class X has no virtual functions [...]
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= SMF_Destructor;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
data().HasTrivialSpecialMembersForCall &= SMF_Destructor;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// C++0x [class]p7:
// A standard-layout class is a class that: [...]
// -- has no virtual functions
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
data().IsStandardLayout = false;
Reinstate r114921, which I've exonerated via a self-host build. Centralize the management of CXXRecordDecl::DefinitionData's Aggregate and PlainOldData bits in CXXRecordDecl itself. Another milepost on the road toward <rdar://problem/8459981>. llvm-svn: 114977
2010-09-29 03:45:33 +08:00
}
}
Centralize the management of CXXRecordDecl::DefinitionData's Empty bit in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>. This reinstates r114924, with one crucial bug fix: we were ignoring the implicit fields created by anonymous structs/unions when updating the bits in CXXRecordDecl, which means that a class/struct containing only an anonymous class/struct would be considered "empty". Hilarity follows. llvm-svn: 114980
2010-09-29 04:38:10 +08:00
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// Notify the listener if an implicit member was added after the definition
// was completed.
if (!isBeingDefined() && D->isImplicit())
if (ASTMutationListener *L = getASTMutationListener())
L->AddedCXXImplicitMember(data().Definition, D);
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
// The kind of special member this declaration is, if any.
unsigned SMKind = 0;
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// Handle constructors.
Centralize the handling of CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for copy-assignment operators. Another step toward <rdar://problem/8459981>. llvm-svn: 114899
2010-09-28 06:06:20 +08:00
if (CXXConstructorDecl *Constructor = dyn_cast<CXXConstructorDecl>(D)) {
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
if (!Constructor->isImplicit()) {
// Note that we have a user-declared constructor.
data().UserDeclaredConstructor = true;
// C++ [class]p4:
// A POD-struct is an aggregate class [...]
// Since the POD bit is meant to be C++03 POD-ness, clear it even if the
// type is technically an aggregate in C++0x since it wouldn't be in 03.
data().PlainOldData = false;
}
Removed deadcode related to addition of constructor decls to a class. llvm-svn: 73650
2009-06-18 06:44:31 +08:00
Clean up trivial default constructors now. hasTrivialDefaultConstructor() really really means it now. Also implement a fun standards bug regarding aggregates. Doug, if you'd like, I can un-implement that bug if you think it is truly a defect. The bug is that non-special-member constructors are never considered user-provided, so the following is an aggregate: struct foo { foo(int); }; It's kind of bad, but the solution isn't obvious - should struct foo { foo (int) = delete; }; be an aggregate or not? Lastly, add a missing initialization to FunctionDecl. llvm-svn: 131101
2011-05-10 05:45:35 +08:00
if (Constructor->isDefaultConstructor()) {
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
SMKind |= SMF_DefaultConstructor;
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
if (Constructor->isUserProvided())
Implement implicit deletion of default constructors. Yes, I'm aware that the diagnostics are awful. Tests to follow. llvm-svn: 131203
2011-05-12 06:34:38 +08:00
data().UserProvidedDefaultConstructor = true;
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
if (Constructor->isConstexpr())
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
data().HasConstexprDefaultConstructor = true;
Fix rejects-valid caused by r261297. r261297 called hasUserProvidedDefaultConstructor() to check if defining a const object is ok. This is incorrect for this example: struct X { template<typename ...T> X(T...); int n; }; const X x; // formerly OK, now bogus error Instead, track if a class has a defaulted default constructor, and disallow a const object for classes that either have defaulted default constructors or if they need an implicit constructor. Bug report and fix approach by Richard Smith, thanks! llvm-svn: 261770
2016-02-25 04:58:14 +08:00
if (Constructor->isDefaulted())
data().HasDefaultedDefaultConstructor = true;
Clean up trivial default constructors now. hasTrivialDefaultConstructor() really really means it now. Also implement a fun standards bug regarding aggregates. Doug, if you'd like, I can un-implement that bug if you think it is truly a defect. The bug is that non-special-member constructors are never considered user-provided, so the following is an aggregate: struct foo { foo(int); }; It's kind of bad, but the solution isn't obvious - should struct foo { foo (int) = delete; }; be an aggregate or not? Lastly, add a missing initialization to FunctionDecl. llvm-svn: 131101
2011-05-10 05:45:35 +08:00
}
Centralize the handling of CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for copy-assignment operators. Another step toward <rdar://problem/8459981>. llvm-svn: 114899
2010-09-28 06:06:20 +08:00
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
if (!FunTmpl) {
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
unsigned Quals;
if (Constructor->isCopyConstructor(Quals)) {
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
SMKind |= SMF_CopyConstructor;
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
if (Quals & Qualifiers::Const)
data().HasDeclaredCopyConstructorWithConstParam = true;
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
} else if (Constructor->isMoveConstructor())
SMKind |= SMF_MoveConstructor;
Centralize the handling of CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for copy-assignment operators. Another step toward <rdar://problem/8459981>. llvm-svn: 114899
2010-09-28 06:06:20 +08:00
}
[Sema] Don't perform aggregate initialization for types with explicit constructors Summary: The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25654 llvm-svn: 288565
2016-12-03 09:26:47 +08:00
// C++11 [dcl.init.aggr]p1: DR1518
Fix defaulted-functions-in-C++98 extension to give the functions the same effect they would have in C++11. In particular, they do not prevent value-initialization from performing zero-initialization, nor do they prevent a struct from being an aggregate. llvm-svn: 290229
2016-12-21 09:57:02 +08:00
// An aggregate is an array or a class with no user-provided, explicit, or
// inherited constructors
if (Constructor->isUserProvided() || Constructor->isExplicit())
[Sema] Don't perform aggregate initialization for types with explicit constructors Summary: The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25654 llvm-svn: 288565
2016-12-03 09:26:47 +08:00
data().Aggregate = false;
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
}
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
// Handle constructors, including those inherited from base classes.
if (CXXConstructorDecl *Constructor =
dyn_cast<CXXConstructorDecl>(DUnderlying)) {
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// Record if we see any constexpr constructors which are neither copy
// nor move constructors.
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
// C++1z [basic.types]p10:
// [...] has at least one constexpr constructor or constructor template
// (possibly inherited from a base class) that is not a copy or move
// constructor [...]
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
if (Constructor->isConstexpr() && !Constructor->isCopyOrMoveConstructor())
Renamings to consistently use 'Constexpr' not 'ConstExpr' when referring to the C++0x 'constexpr' keyword. llvm-svn: 137230
2011-08-11 02:11:37 +08:00
data().HasConstexprNonCopyMoveConstructor = true;
"This patch implements the restrictions on union members detailed in [class.union]p1", from John McCall! llvm-svn: 76766
2009-07-23 02:25:24 +08:00
}
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// Handle destructors.
Implement the new C++0x rules for non-trivial things in unions so that my defaulted constructor tests stop yelling at me about them. llvm-svn: 131432
2011-05-17 06:41:40 +08:00
if (CXXDestructorDecl *DD = dyn_cast<CXXDestructorDecl>(D)) {
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
SMKind |= SMF_Destructor;
Teach CXXRecordDecl::hasIrrelevantDestructor to check the base classes and data members for deleted or user-provided destructors. Now it's computed in advance, serialize it, and in passing fix all the other record DefinitionData flags whose serialization was missing. llvm-svn: 151441
2012-02-25 15:33:38 +08:00
Recognize simple cases of trivial explicitly defaulted public dtors as irrelevant Reviewed in http://llvm-reviews.chandlerc.com/D3190 llvm-svn: 204953
2014-03-28 04:23:12 +08:00
if (DD->isUserProvided())
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
data().HasIrrelevantDestructor = false;
Recognize simple cases of trivial explicitly defaulted public dtors as irrelevant Reviewed in http://llvm-reviews.chandlerc.com/D3190 llvm-svn: 204953
2014-03-28 04:23:12 +08:00
// If the destructor is explicitly defaulted and not trivial or not public
// or if the destructor is deleted, we clear HasIrrelevantDestructor in
// finishedDefaultedOrDeletedMember.
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// C++11 [class.dtor]p5:
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
// A destructor is trivial if [...] the destructor is not virtual.
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
if (DD->isVirtual()) {
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_Destructor;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
data().HasTrivialSpecialMembersForCall &= ~SMF_Destructor;
}
Centralize the handling of CXXRecordDecl::DefinitionData's DeclaredDestructor and UserDeclaredDestructor bits in CXXRecordDecl itself. Another step on the road to <rdar://problem/8459981>. llvm-svn: 114918
2010-09-28 06:48:58 +08:00
}
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// Handle member functions.
Centralize the handling of CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for copy-assignment operators. Another step toward <rdar://problem/8459981>. llvm-svn: 114899
2010-09-28 06:06:20 +08:00
if (CXXMethodDecl *Method = dyn_cast<CXXMethodDecl>(D)) {
Implement a little bit of cleanup and a lot more of the base work behind implicit moves. We now correctly identify move constructors and assignment operators and update bits on the record correctly. Generation of implicit moves (declarations or definitions) is not yet supported. llvm-svn: 132080
2011-05-26 04:50:04 +08:00
if (Method->isCopyAssignmentOperator()) {
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
SMKind |= SMF_CopyAssignment;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
const ReferenceType *ParamTy =
Method->getParamDecl(0)->getType()->getAs<ReferenceType>();
if (!ParamTy || ParamTy->getPointeeType().isConstQualified())
data().HasDeclaredCopyAssignmentWithConstParam = true;
Implement a little bit of cleanup and a lot more of the base work behind implicit moves. We now correctly identify move constructors and assignment operators and update bits on the record correctly. Generation of implicit moves (declarations or definitions) is not yet supported. llvm-svn: 132080
2011-05-26 04:50:04 +08:00
}
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
if (Method->isMoveAssignmentOperator())
SMKind |= SMF_MoveAssignment;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
Move the management of the set of conversion functions in a C++ class into CXXRecordDecl. The only part that we do not handle this way are using declarations, since that would require extra name lookup that we don't currently want to pay for. This fixes <rdar://problem/8459981>, so that LLDB can build a CXXRecordDecl and magically get all of the right bits set. llvm-svn: 115026
2010-09-29 12:25:11 +08:00
// Keep the list of conversion functions up-to-date.
if (CXXConversionDecl *Conversion = dyn_cast<CXXConversionDecl>(D)) {
<rdar://problem/12806802> Propagate access specifiers for conversion functions to the conversion function set eagerly. This slightly propagates an existing hack that delays when we provide access specifiers for the visible conversion functions of a class by copying the available access specifier early. The only client this affects is LLDB, which tends to discover and add conversion functions after the class is technically "complete". As such, the only observable difference is in LLDB, so the testing will go there. llvm-svn: 179029
2013-04-09 01:12:58 +08:00
// FIXME: We use the 'unsafe' accessor for the access specifier here,
// because Sema may not have set it yet. That's really just a misdesign
// in Sema. However, LLDB *will* have set the access specifier correctly,
// and adds declarations after the class is technically completed,
// so completeDefinition()'s overriding of the access specifiers doesn't
// work.
AccessSpecifier AS = Conversion->getAccessUnsafe();
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
if (Conversion->getPrimaryTemplate()) {
// We don't record specializations.
Move the management of the set of conversion functions in a C++ class into CXXRecordDecl. The only part that we do not handle this way are using declarations, since that would require extra name lookup that we don't currently want to pay for. This fixes <rdar://problem/8459981>, so that LLDB can build a CXXRecordDecl and magically get all of the right bits set. llvm-svn: 115026
2010-09-29 12:25:11 +08:00
} else {
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
ASTContext &Ctx = getASTContext();
ASTUnresolvedSet &Conversions = data().Conversions.get(Ctx);
NamedDecl *Primary =
FunTmpl ? cast<NamedDecl>(FunTmpl) : cast<NamedDecl>(Conversion);
if (Primary->getPreviousDecl())
Conversions.replace(cast<NamedDecl>(Primary->getPreviousDecl()),
Primary, AS);
Move the management of the set of conversion functions in a C++ class into CXXRecordDecl. The only part that we do not handle this way are using declarations, since that would require extra name lookup that we don't currently want to pay for. This fixes <rdar://problem/8459981>, so that LLDB can build a CXXRecordDecl and magically get all of the right bits set. llvm-svn: 115026
2010-09-29 12:25:11 +08:00
else
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
Conversions.addDecl(Ctx, Primary, AS);
Move the management of the set of conversion functions in a C++ class into CXXRecordDecl. The only part that we do not handle this way are using declarations, since that would require extra name lookup that we don't currently want to pay for. This fixes <rdar://problem/8459981>, so that LLDB can build a CXXRecordDecl and magically get all of the right bits set. llvm-svn: 115026
2010-09-29 12:25:11 +08:00
}
}
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
if (SMKind) {
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
// If this is the first declaration of a special member, we no longer have
// an implicit trivial special member.
data().HasTrivialSpecialMembers &=
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
data().DeclaredSpecialMembers | ~SMKind;
data().HasTrivialSpecialMembersForCall &=
data().DeclaredSpecialMembers | ~SMKind;
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
if (!Method->isImplicit() && !Method->isUserProvided()) {
// This method is user-declared but not user-provided. We can't work out
// whether it's trivial yet (not until we get to the end of the class).
// We'll handle this method in finishedDefaultedOrDeletedMember.
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
} else if (Method->isTrivial()) {
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
data().HasTrivialSpecialMembers |= SMKind;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
data().HasTrivialSpecialMembersForCall |= SMKind;
} else if (Method->isTrivialForCall()) {
data().HasTrivialSpecialMembersForCall |= SMKind;
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
data().DeclaredNonTrivialSpecialMembers |= SMKind;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
} else {
data().DeclaredNonTrivialSpecialMembers |= SMKind;
// If this is a user-provided function, do not set
// DeclaredNonTrivialSpecialMembersForCall here since we don't know
// yet whether the method would be considered non-trivial for the
// purpose of calls (attribute "trivial_abi" can be dropped from the
// class later, which can change the special method's triviality).
if (!Method->isUserProvided())
data().DeclaredNonTrivialSpecialMembersForCall |= SMKind;
}
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
// Note when we have declared a declared special member, and suppress the
// implicit declaration of this special member.
data().DeclaredSpecialMembers |= SMKind;
if (!Method->isImplicit()) {
data().UserDeclaredSpecialMembers |= SMKind;
// C++03 [class]p4:
// A POD-struct is an aggregate class that has [...] no user-defined
// copy assignment operator and no user-defined destructor.
//
// Since the POD bit is meant to be C++03 POD-ness, and in C++03,
// aggregates could not have any constructors, clear it even for an
// explicitly defaulted or deleted constructor.
// type is technically an aggregate in C++0x since it wouldn't be in 03.
//
// Also, a user-declared move assignment operator makes a class non-POD.
// This is an extension in C++03.
data().PlainOldData = false;
}
}
PODness and Type Traits Make C++ classes track the POD property (C++ [class]p4) Track the existence of a copy assignment operator. Implicitly declare the copy assignment operator if none is provided. Implement most of the parsing job for the G++ type traits extension. Fully implement the low-hanging fruit of the type traits: __is_pod: Whether a type is a POD. __is_class: Whether a type is a (non-union) class. __is_union: Whether a type is a union. __is_enum: Whether a type is an enum. __is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1). llvm-svn: 61746
2009-01-06 04:52:13 +08:00
return;
Centralize the handling of CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for copy-assignment operators. Another step toward <rdar://problem/8459981>. llvm-svn: 114899
2010-09-28 06:06:20 +08:00
}
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
Reinstate r114921, which I've exonerated via a self-host build. Centralize the management of CXXRecordDecl::DefinitionData's Aggregate and PlainOldData bits in CXXRecordDecl itself. Another milepost on the road toward <rdar://problem/8459981>. llvm-svn: 114977
2010-09-29 03:45:33 +08:00
// Handle non-static data members.
if (FieldDecl *Field = dyn_cast<FieldDecl>(D)) {
Per C++ [class.bit]p2, unnamed bit-fields are not members. Fixes PR10289. llvm-svn: 141549
2011-10-11 01:22:13 +08:00
// C++ [class.bit]p2:
// A declaration for a bit-field that omits the identifier declares an
// unnamed bit-field. Unnamed bit-fields are not members and cannot be
// initialized.
if (Field->isUnnamedBitfield())
return;
Reinstate r114921, which I've exonerated via a self-host build. Centralize the management of CXXRecordDecl::DefinitionData's Aggregate and PlainOldData bits in CXXRecordDecl itself. Another milepost on the road toward <rdar://problem/8459981>. llvm-svn: 114977
2010-09-29 03:45:33 +08:00
// C++ [dcl.init.aggr]p1:
// An aggregate is an array or a class (clause 9) with [...] no
// private or protected non-static data members (clause 11).
//
// A POD must be an aggregate.
if (D->getAccess() == AS_private || D->getAccess() == AS_protected) {
data().Aggregate = false;
data().PlainOldData = false;
}
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// C++0x [class]p7:
// A standard-layout class is a class that:
// [...]
// -- has the same access control for all non-static data members,
switch (D->getAccess()) {
case AS_private: data().HasPrivateFields = true; break;
case AS_protected: data().HasProtectedFields = true; break;
case AS_public: data().HasPublicFields = true; break;
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
case AS_none: llvm_unreachable("Invalid access specifier");
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
};
if ((data().HasPrivateFields + data().HasProtectedFields +
data().HasPublicFields) > 1)
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
data().IsStandardLayout = false;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
When determining whether we can make a declaration into a global constant, also consider whether it's a class type that has any mutable fields. If so, it can't be a global constant. llvm-svn: 131276
2011-05-13 09:05:07 +08:00
// Keep track of the presence of mutable fields.
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
if (Field->isMutable()) {
When determining whether we can make a declaration into a global constant, also consider whether it's a class type that has any mutable fields. If so, it can't be a global constant. llvm-svn: 131276
2011-05-13 09:05:07 +08:00
data().HasMutableFields = true;
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
data().NeedOverloadResolutionForCopyConstructor = true;
}
Implement DR1460: fix handling of default initializers in unions; don't allow more than one such initializer in a union, make mem-initializers override default initializers for other union members, handle anonymous unions with anonymous struct members better. Fix a couple of semi-related bugs exposed by the tests for same. llvm-svn: 196892
2013-12-10 16:25:00 +08:00
// C++11 [class.union]p8, DR1460:
// If X is a union, a non-static data member of X that is not an anonymous
// union is a variant member of X.
if (isUnion() && !Field->isAnonymousStructOrUnion())
data().HasVariantMembers = true;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
// C++0x [class]p9:
Reinstate r114921, which I've exonerated via a self-host build. Centralize the management of CXXRecordDecl::DefinitionData's Aggregate and PlainOldData bits in CXXRecordDecl itself. Another milepost on the road toward <rdar://problem/8459981>. llvm-svn: 114977
2010-09-29 03:45:33 +08:00
// A POD struct is a class that is both a trivial class and a
// standard-layout class, and has no non-static data members of type
// non-POD struct, non-POD union (or array of such types).
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
//
// Automatic Reference Counting: the presence of a member of Objective-C pointer type
// that does not explicitly have no lifetime makes the class a non-POD.
Reinstate r114921, which I've exonerated via a self-host build. Centralize the management of CXXRecordDecl::DefinitionData's Aggregate and PlainOldData bits in CXXRecordDecl itself. Another milepost on the road toward <rdar://problem/8459981>. llvm-svn: 114977
2010-09-29 03:45:33 +08:00
ASTContext &Context = getASTContext();
QualType T = Context.getBaseElementType(Field->getType());
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
if (T->isObjCRetainableType() || T.isObjCGCStrong()) {
[Objective-C] C++ Classes with __weak Members non-POD Types when using -fobjc-weak Summary: When adding an Objective-C retainable type member to a C++ class, also check the LangOpts.ObjCWeak flag and the lifetime qualifier so __weak qualified Objective-C pointer members cause the class to be a non-POD type with non-trivial special members, so the compiler always emits the necessary runtime calls for copying, moving, and destroying the weak member. Otherwise, Objective-C++ classes with weak Objective-C pointer members compiled with -fobjc-weak exhibit undefined behavior if the C++ class is classified as a POD type. Reviewers: rsmith, benlangmuir, doug.gregor, rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31003 llvm-svn: 299008
2017-03-30 01:31:42 +08:00
if (T.hasNonTrivialObjCLifetime()) {
Fix an assertion failure trying to emit a trivial destructor in ObjC++ If a base class declares a destructor, we will add the implicit destructor for the subclass in ActOnFields -> AddImplicitlyDeclaredMembersToClass But in Objective C++, we did not compute whether we have a trivial destructor until after that in CXXRecordDecl::completeDefinition() This was leading to a mismatch between the class, which thought it had no trivial destructor, and the CXXDestructorDecl, which considered itself trivial. It turns out the reason we delayed setting this until completeDefinition() was for a warning that has since been removed as part of -Warc-abi, so we just do it eagerly now. llvm-svn: 218520
2014-09-26 23:27:29 +08:00
// Objective-C Automatic Reference Counting:
// If a class has a non-static data member of Objective-C pointer
// type (or array thereof), it is a non-POD type and its
// default constructor (if any), copy constructor, move constructor,
// copy assignment operator, move assignment operator, and destructor are
// non-trivial.
setHasObjectMember(true);
struct DefinitionData &Data = data();
Data.PlainOldData = false;
Data.HasTrivialSpecialMembers = 0;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
Data.HasTrivialSpecialMembersForCall = 0;
Fix an assertion failure trying to emit a trivial destructor in ObjC++ If a base class declares a destructor, we will add the implicit destructor for the subclass in ActOnFields -> AddImplicitlyDeclaredMembersToClass But in Objective C++, we did not compute whether we have a trivial destructor until after that in CXXRecordDecl::completeDefinition() This was leading to a mismatch between the class, which thought it had no trivial destructor, and the CXXDestructorDecl, which considered itself trivial. It turns out the reason we delayed setting this until completeDefinition() was for a warning that has since been removed as part of -Warc-abi, so we just do it eagerly now. llvm-svn: 218520
2014-09-26 23:27:29 +08:00
Data.HasIrrelevantDestructor = false;
[Objective-C] C++ Classes with __weak Members non-POD Types when using -fobjc-weak Summary: When adding an Objective-C retainable type member to a C++ class, also check the LangOpts.ObjCWeak flag and the lifetime qualifier so __weak qualified Objective-C pointer members cause the class to be a non-POD type with non-trivial special members, so the compiler always emits the necessary runtime calls for copying, moving, and destroying the weak member. Otherwise, Objective-C++ classes with weak Objective-C pointer members compiled with -fobjc-weak exhibit undefined behavior if the C++ class is classified as a POD type. Reviewers: rsmith, benlangmuir, doug.gregor, rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31003 llvm-svn: 299008
2017-03-30 01:31:42 +08:00
} else if (!Context.getLangOpts().ObjCAutoRefCount) {
setHasObjectMember(true);
Fix an assertion failure trying to emit a trivial destructor in ObjC++ If a base class declares a destructor, we will add the implicit destructor for the subclass in ActOnFields -> AddImplicitlyDeclaredMembersToClass But in Objective C++, we did not compute whether we have a trivial destructor until after that in CXXRecordDecl::completeDefinition() This was leading to a mismatch between the class, which thought it had no trivial destructor, and the CXXDestructorDecl, which considered itself trivial. It turns out the reason we delayed setting this until completeDefinition() was for a warning that has since been removed as part of -Warc-abi, so we just do it eagerly now. llvm-svn: 218520
2014-09-26 23:27:29 +08:00
}
Fix bug in computing POD-for-layout. A class with a field of non-POD-for-layout type is not POD-for-layout. This computation should not depend on whether the field is of POD type in the language sense. Fixes PR16537. Patch by Josh Magee. llvm-svn: 186741
2013-07-20 09:06:31 +08:00
} else if (!T.isCXX98PODType(Context))
Reinstate r114921, which I've exonerated via a self-host build. Centralize the management of CXXRecordDecl::DefinitionData's Aggregate and PlainOldData bits in CXXRecordDecl itself. Another milepost on the road toward <rdar://problem/8459981>. llvm-svn: 114977
2010-09-29 03:45:33 +08:00
data().PlainOldData = false;
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
if (T->isReferenceType()) {
Implement C++03 [dcl.init]p5's checking for value-initialization of references properly, rather than faking it up by pretending that a reference member makes the default constructor non-trivial. That leads to rejects-valids when putting such types inside unions. llvm-svn: 169662
2012-12-08 10:01:17 +08:00
if (!Field->hasInClassInitializer())
data().HasUninitializedReferenceMember = true;
Implement most of the remaining logic in __is_literal type trait. This should now support all of the C++98 types, and all of the C++0x types Clang supports. llvm-svn: 130079
2011-04-24 10:49:34 +08:00
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// C++0x [class]p7:
// A standard-layout class is a class that:
// -- has no non-static data members of type [...] reference,
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
data().IsStandardLayout = false;
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
// C++1z [class.copy.ctor]p10:
// A defaulted copy constructor for a class X is defined as deleted if X has:
// -- a non-static data member of rvalue reference type
if (T->isRValueReferenceType())
data().DefaultedCopyConstructorIsDeleted = true;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
}
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
if (!Field->hasInClassInitializer() && !Field->isMutable()) {
Fix implementation of the likely resolution of core issue 253 to support class based arrays. Patch by Ian Tessier! Differential Review: https://reviews.llvm.org/D25974 llvm-svn: 285430
2016-10-29 03:11:18 +08:00
if (CXXRecordDecl *FieldType = T->getAsCXXRecordDecl()) {
Fix SemaTemplate/instantiate-field.cpp after r261297. For templates, fields can have incomplete types: template <class T> struct A2 { struct B; B b; }; Don't try to touch the DefinitionData of those fields. llvm-svn: 261301
2016-02-19 10:51:07 +08:00
if (FieldType->hasDefinition() && !FieldType->allowConstDefaultInit())
Implement the likely resolution of core issue 253. C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
2016-02-19 09:52:46 +08:00
data().HasUninitializedFields = true;
} else {
data().HasUninitializedFields = true;
}
}
Update constexpr implementation to match CWG's chosen approach for core issues 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
2012-02-13 11:54:03 +08:00
// Record if this field is the first non-literal or volatile field or base.
C++1y constexpr extensions, round 1: Allow most forms of declaration and 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
2013-04-22 23:31:51 +08:00
if (!T->isLiteralType(Context) || T.isVolatileQualified())
Implement most of the remaining logic in __is_literal type trait. This should now support all of the C++98 types, and all of the C++0x types Clang supports. llvm-svn: 130079
2011-04-24 10:49:34 +08:00
data().HasNonLiteralTypeFieldsOrBases = true;
Implement DR1460: fix handling of default initializers in unions; don't allow more than one such initializer in a union, make mem-initializers override default initializers for other union members, handle anonymous unions with anonymous struct members better. Fix a couple of semi-related bugs exposed by the tests for same. llvm-svn: 196892
2013-12-10 16:25:00 +08:00
if (Field->hasInClassInitializer() ||
(Field->isAnonymousStructOrUnion() &&
Field->getType()->getAsCXXRecordDecl()->hasInClassInitializer())) {
A union can have a constexpr defaulted default constructor, if it has an 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
2012-05-07 09:07:30 +08:00
data().HasInClassInitializer = true;
// C++11 [class]p5:
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
// A default constructor is trivial if [...] no non-static data member
// of its class has a brace-or-equal-initializer.
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_DefaultConstructor;
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
A union can have a constexpr defaulted default constructor, if it has an 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
2012-05-07 09:07:30 +08:00
// C++11 [dcl.init.aggr]p1:
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
// An aggregate is a [...] class with [...] no
// brace-or-equal-initializers for non-static data members.
C++1y: Allow aggregates to have default initializers. Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in CXXCtorInitializers and in InitListExprs to represent a default initializer. There's an additional complication here: because the default initializer can refer to the initialized object via its 'this' pointer, we need to make sure that 'this' points to the right thing within the evaluation. llvm-svn: 179958
2013-04-21 06:23:05 +08:00
//
P0017R1: In C++1z, an aggregate class can have (public non-virtual) base classes; these are initialized as if they were data members. llvm-svn: 262963
2016-03-09 06:17:41 +08:00
// This rule was removed in C++14.
C++1y is now C++14! Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording. llvm-svn: 215982
2014-08-19 23:55:55 +08:00
if (!getASTContext().getLangOpts().CPlusPlus14)
C++1y: Allow aggregates to have default initializers. Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in CXXCtorInitializers and in InitListExprs to represent a default initializer. There's an additional complication here: because the default initializer can refer to the initialized object via its 'this' pointer, we need to make sure that 'this' points to the right thing within the evaluation. llvm-svn: 179958
2013-04-21 06:23:05 +08:00
data().Aggregate = false;
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
A union can have a constexpr defaulted default constructor, if it has an 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
2012-05-07 09:07:30 +08:00
// C++11 [class]p10:
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
// A POD struct is [...] a trivial class.
data().PlainOldData = false;
}
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
// C++11 [class.copy]p23:
// A defaulted copy/move assignment operator for a class X is defined
// as deleted if X has:
// -- a non-static data member of reference type
if (T->isReferenceType())
data().DefaultedMoveAssignmentIsDeleted = true;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
if (const RecordType *RecordTy = T->getAs<RecordType>()) {
CXXRecordDecl* FieldRec = cast<CXXRecordDecl>(RecordTy->getDecl());
if (FieldRec->getDefinition()) {
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
addedClassSubobject(FieldRec);
Take cv-qualifiers on fields of class type into account when determining whether a defaulted special member function should be deleted. llvm-svn: 195620
2013-11-25 15:07:05 +08:00
// We may need to perform overload resolution to determine whether a
// field can be moved if it's const or volatile qualified.
if (T.getCVRQualifiers() & (Qualifiers::Const | Qualifiers::Volatile)) {
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
// We need to care about 'const' for the copy constructor because an
// implicit copy constructor might be declared with a non-const
// parameter.
data().NeedOverloadResolutionForCopyConstructor = true;
Take cv-qualifiers on fields of class type into account when determining whether a defaulted special member function should be deleted. llvm-svn: 195620
2013-11-25 15:07:05 +08:00
data().NeedOverloadResolutionForMoveConstructor = true;
data().NeedOverloadResolutionForMoveAssignment = true;
}
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
// C++11 [class.ctor]p5, C++11 [class.copy]p11:
// A defaulted [special member] for a class X is defined as
// deleted if:
// -- X is a union-like class that has a variant member with a
// non-trivial [corresponding special member]
if (isUnion()) {
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
if (FieldRec->hasNonTrivialCopyConstructor())
data().DefaultedCopyConstructorIsDeleted = true;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
if (FieldRec->hasNonTrivialMoveConstructor())
data().DefaultedMoveConstructorIsDeleted = true;
if (FieldRec->hasNonTrivialMoveAssignment())
data().DefaultedMoveAssignmentIsDeleted = true;
if (FieldRec->hasNonTrivialDestructor())
data().DefaultedDestructorIsDeleted = true;
}
PR28978: If we need overload resolution for the move constructor of an anonymous union member of a class, we need overload resolution for the move constructor of the class itself too; we can't rely on Sema to do the right thing for us for anonymous union types. llvm-svn: 278763
2016-08-16 08:13:47 +08:00
// For an anonymous union member, our overload resolution will perform
// overload resolution for its members.
if (Field->isAnonymousStructOrUnion()) {
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
data().NeedOverloadResolutionForCopyConstructor |=
FieldRec->data().NeedOverloadResolutionForCopyConstructor;
PR28978: If we need overload resolution for the move constructor of an anonymous union member of a class, we need overload resolution for the move constructor of the class itself too; we can't rely on Sema to do the right thing for us for anonymous union types. llvm-svn: 278763
2016-08-16 08:13:47 +08:00
data().NeedOverloadResolutionForMoveConstructor |=
FieldRec->data().NeedOverloadResolutionForMoveConstructor;
data().NeedOverloadResolutionForMoveAssignment |=
FieldRec->data().NeedOverloadResolutionForMoveAssignment;
data().NeedOverloadResolutionForDestructor |=
FieldRec->data().NeedOverloadResolutionForDestructor;
}
Rename "hasTrivialConstructor" to "hasTrivialDefaultConstructor" and modify the semantics slightly to accomodate default constructors (I hope). llvm-svn: 131087
2011-05-10 02:22:59 +08:00
// C++0x [class.ctor]p5:
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
// A default constructor is trivial [...] if:
Rename "hasTrivialConstructor" to "hasTrivialDefaultConstructor" and modify the semantics slightly to accomodate default constructors (I hope). llvm-svn: 131087
2011-05-10 02:22:59 +08:00
// -- for all the non-static data members of its class that are of
// class type (or array thereof), each such class has a trivial
// default constructor.
if (!FieldRec->hasTrivialDefaultConstructor())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_DefaultConstructor;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
// C++0x [class.copy]p13:
// A copy/move constructor for class X is trivial if [...]
// [...]
// -- for each non-static data member of X that is of class type (or
// an array thereof), the constructor selected to copy/move that
// member is trivial;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
if (!FieldRec->hasTrivialCopyConstructor())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_CopyConstructor;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
if (!FieldRec->hasTrivialCopyConstructorForCall())
data().HasTrivialSpecialMembersForCall &= ~SMF_CopyConstructor;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
// If the field doesn't have a simple move constructor, we'll eagerly
// declare the move constructor for this class and we'll decide whether
// it's trivial then.
A step towards sorting out handling of triviality of special members in C++11. Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
2012-11-16 08:53:38 +08:00
if (!FieldRec->hasTrivialMoveConstructor())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_MoveConstructor;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
if (!FieldRec->hasTrivialMoveConstructorForCall())
data().HasTrivialSpecialMembersForCall &= ~SMF_MoveConstructor;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
// C++0x [class.copy]p27:
// A copy/move assignment operator for class X is trivial if [...]
// [...]
// -- for each non-static data member of X that is of class type (or
// an array thereof), the assignment operator selected to
// copy/move that member is trivial;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
if (!FieldRec->hasTrivialCopyAssignment())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_CopyAssignment;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
// If the field doesn't have a simple move assignment, we'll eagerly
// declare the move assignment for this class and we'll decide whether
// it's trivial then.
A step towards sorting out handling of triviality of special members in C++11. Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
2012-11-16 08:53:38 +08:00
if (!FieldRec->hasTrivialMoveAssignment())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_MoveAssignment;
Begin tracking trivialness of move constructors and move assignment operators in C++ record declarations. This patch starts off by updating a bunch of the standard citations to refer to the draft 0x standard so that the semantics intended for move varianst is clear. Where necessary these are duplicated so they'll be available in doxygen. It adds bit fields to keep track of the state for the move constructs, and updates all the code necessary to track this state (I think) as members are declared for a class. It also wires the state into the various trait-like accessors in the AST's API, and tests that the type trait expressions now behave correctly in the presence of move constructors and move assignment operators. This isn't complete yet due to these glaring FIXMEs: 1) No synthesis of implicit move constructors or assignment operators. 2) I don't think we correctly enforce the new logic for both copy and move trivial checks: that the *selected* copy/move constructor/operator is trivial. Currently this requires *all* of them to be trivial. 3) Some of the trait logic needs to be folded into the fine-grained trivial bits to more closely match the wording of the standard. For example, many of the places we currently set a bit to track POD-ness could be removed by querying other more fine grained traits on demand. llvm-svn: 130076
2011-04-24 07:10:33 +08:00
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
if (!FieldRec->hasTrivialDestructor())
Refactor to reduce duplication in handling of special member functions. No functionality change. llvm-svn: 168977
2012-11-30 13:11:39 +08:00
data().HasTrivialSpecialMembers &= ~SMF_Destructor;
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
if (!FieldRec->hasTrivialDestructorForCall())
data().HasTrivialSpecialMembersForCall &= ~SMF_Destructor;
Teach CXXRecordDecl::hasIrrelevantDestructor to check the base classes and data members for deleted or user-provided destructors. Now it's computed in advance, serialize it, and in passing fix all the other record DefinitionData flags whose serialization was missing. llvm-svn: 151441
2012-02-25 15:33:38 +08:00
if (!FieldRec->hasIrrelevantDestructor())
data().HasIrrelevantDestructor = false;
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
if (FieldRec->hasObjectMember())
setHasObjectMember(true);
patch for PR9027 and // rdar://11861085 Title: [PR9027] volatile struct bug: member is not loaded at -O; This is caused by last flag passed to @llvm.memcpy being false, not honoring that aggregate has at least one 'volatile' data member (even though aggregate itself has not been qualified as 'volatile'. As a result, optimization optimizes away the memcpy altogether. Patch review by John MaCall (I still need to fix up a test though). llvm-svn: 173535
2013-01-26 07:57:05 +08:00
if (FieldRec->hasVolatileMember())
setHasVolatileMember(true);
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// C++0x [class]p7:
// A standard-layout class is a class that:
// -- has no non-static data members of type non-standard-layout
// class (or array of such types) [...]
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
if (!FieldRec->isStandardLayout())
data().IsStandardLayout = false;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// C++0x [class]p7:
// A standard-layout class is a class that:
// [...]
// -- has no base classes of the same type as the first non-static
// data member.
// We don't want to expend bits in the state of the record decl
// tracking whether this is the first non-static data member so we
// cheat a bit and use some of the existing state: the empty bit.
// Virtual bases and virtual methods make a class non-empty, but they
// also make it non-standard-layout so we needn't check here.
// A non-empty base class may leave the class standard-layout, but not
Implement DR1460: fix handling of default initializers in unions; don't allow more than one such initializer in a union, make mem-initializers override default initializers for other union members, handle anonymous unions with anonymous struct members better. Fix a couple of semi-related bugs exposed by the tests for same. llvm-svn: 196892
2013-12-10 16:25:00 +08:00
// if we have arrived here, and have at least one non-static data
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
// member. If IsStandardLayout remains true, then the first non-static
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// data member must come through here with Empty still true, and Empty
// will subsequently be set to false below.
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
if (data().IsStandardLayout && data().Empty) {
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
for (const auto &BI : bases()) {
if (Context.hasSameUnqualifiedType(BI.getType(), T)) {
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
data().IsStandardLayout = false;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
break;
}
}
}
When determining whether we can make a declaration into a global constant, also consider whether it's a class type that has any mutable fields. If so, it can't be a global constant. llvm-svn: 131276
2011-05-13 09:05:07 +08:00
// Keep track of the presence of mutable fields.
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
if (FieldRec->hasMutableFields()) {
When determining whether we can make a declaration into a global constant, also consider whether it's a class type that has any mutable fields. If so, it can't be a global constant. llvm-svn: 131276
2011-05-13 09:05:07 +08:00
data().HasMutableFields = true;
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
data().NeedOverloadResolutionForCopyConstructor = true;
}
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
// C++11 [class.copy]p13:
// If the implicitly-defined constructor would satisfy the
// requirements of a constexpr constructor, the implicitly-defined
// constructor is constexpr.
// C++11 [dcl.constexpr]p4:
// -- every constructor involved in initializing non-static data
// members [...] shall be a constexpr constructor
if (!Field->hasInClassInitializer() &&
A union can have a constexpr defaulted default constructor, if it has an 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
2012-05-07 09:07:30 +08:00
!FieldRec->hasConstexprDefaultConstructor() && !isUnion())
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
// The standard requires any in-class initializer to be a constant
// expression. We consider this to be a defect.
data().DefaultedDefaultConstructorIsConstexpr = false;
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// C++11 [class.copy]p8:
// The implicitly-declared copy constructor for a class X will have
C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
2017-02-26 07:53:05 +08:00
// the form 'X::X(const X&)' if each potentially constructed subobject
// of a class type M (or array thereof) has a copy constructor whose
// first parameter is of type 'const M&' or 'const volatile M&'.
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
if (!FieldRec->hasCopyConstructorWithConstParam())
C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
2017-02-26 07:53:05 +08:00
data().ImplicitCopyConstructorCanHaveConstParamForNonVBase = false;
Store on the CXXRecordDecl whether the class has, or would have, a copy constructor/assignment operator with a const-qualified parameter type. The prior method for determining this incorrectly used overload resolution. llvm-svn: 168775
2012-11-28 14:23:12 +08:00
// C++11 [class.copy]p18:
// The implicitly-declared copy assignment oeprator for a class X will
// have the form 'X& X::operator=(const X&)' if [...] for all the
// non-static data members of X that are of a class type M (or array
// thereof), each such class type has a copy assignment operator whose
// parameter is of type 'const M&', 'const volatile M&' or 'M'.
if (!FieldRec->hasCopyAssignmentWithConstParam())
data().ImplicitCopyAssignmentHasConstParam = false;
Implement C++03 [dcl.init]p5's checking for value-initialization of references properly, rather than faking it up by pretending that a reference member makes the default constructor non-trivial. That leads to rejects-valids when putting such types inside unions. llvm-svn: 169662
2012-12-08 10:01:17 +08:00
if (FieldRec->hasUninitializedReferenceMember() &&
!Field->hasInClassInitializer())
data().HasUninitializedReferenceMember = true;
Implement DR1460: fix handling of default initializers in unions; don't allow more than one such initializer in a union, make mem-initializers override default initializers for other union members, handle anonymous unions with anonymous struct members better. Fix a couple of semi-related bugs exposed by the tests for same. llvm-svn: 196892
2013-12-10 16:25:00 +08:00
// C++11 [class.union]p8, DR1460:
// a non-static data member of an anonymous union that is a member of
// X is also a variant member of X.
if (FieldRec->hasVariantMembers() &&
Field->isAnonymousStructOrUnion())
data().HasVariantMembers = true;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
}
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
} else {
// Base element type of field is a non-class type.
C++1y constexpr extensions, round 1: Allow most forms of declaration and 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
2013-04-22 23:31:51 +08:00
if (!T->isLiteralType(Context) ||
Remove CXXRecordDecl flags which are unused after r158289. We need an efficient mechanism to determine whether a defaulted default constructor is constexpr, in order to determine whether a class is a literal type, so keep the incrementally-built form on CXXRecordDecl. Remove the on-demand computation of same, so that we only have one method for determining whether a default constructor is constexpr. This doesn't affect correctness, since default constructor lookup is much simpler than selecting a constructor for copying or moving. We don't need a corresponding mechanism for defaulted copy or move constructors, since they can't affect whether a type is a literal type. Conversely, checking whether such functions are constexpr can require non-trivial effort, so we defer such checks until the copy or move constructor is required. Thus we now only compute whether a copy or move constructor is constexpr on demand, and only compute whether a default constructor is constexpr in advance. This is unfortunate, but seems like the best solution. llvm-svn: 158290
2012-06-10 15:07:24 +08:00
(!Field->hasInClassInitializer() && !isUnion()))
PR11614: Mark defaulted special constructors as constexpr if their implicit definition would satisfy the constexpr requirements. llvm-svn: 147128
2011-12-22 10:22:31 +08:00
data().DefaultedDefaultConstructorIsConstexpr = false;
Finish implementing 'selected constructor' rules for triviality in C++11. In the cases where we can't determine whether special members would be trivial while building the class, we eagerly declare those special members. The impact of this is bounded, since it does not trigger implicit declarations of special members in classes which merely *use* those classes. In order to determine whether we need to apply this rule, we also need to eagerly declare move operations and destructors in cases where they might be deleted. If a move operation were supposed to be deleted, it would instead be suppressed, and we could need overload resolution to determine if we fall back to a trivial copy operation. If a destructor were implicitly deleted, it would cause the move constructor of any derived classes to be suppressed. As discussed on cxx-abi-dev, C++11's selected constructor rules are also retroactively applied as a defect resolution in C++03 mode, in order to identify that class B has a non-trivial copy constructor (since it calls A's constructor template, not A's copy constructor): struct A { template<typename T> A(T &); }; struct B { mutable A a; }; llvm-svn: 169673
2012-12-08 16:32:28 +08:00
// C++11 [class.copy]p23:
// A defaulted copy/move assignment operator for a class X is defined
// as deleted if X has:
// -- a non-static data member of const non-class type (or array
// thereof)
if (T.isConstQualified())
data().DefaultedMoveAssignmentIsDeleted = true;
Reinstate r114925 and r114929, both steps toward <rdar://problem/8459981>. llvm-svn: 114984
2010-09-29 04:50:54 +08:00
}
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
// C++0x [class]p7:
// A standard-layout class is a class that:
// [...]
// -- either has no non-static data members in the most derived
// class and at most one base class with non-static data members,
// or has no base classes with non-static data members, and
// At this point we know that we have a non-static data member, so the last
// clause holds.
if (!data().HasNoNonEmptyBases)
Rename the last '[hH]asStandardLayout' entites to '[iI]sStandardLayout' based on Doug's preferences when we discussed this in IRC. This brings the wording more in line with the standard. llvm-svn: 130603
2011-04-30 18:07:30 +08:00
data().IsStandardLayout = false;
Completely re-implement the core logic behind the __is_standard_layout type trait. The previous implementation suffered from several problems: 1) It implemented all of the logic in RecordType by walking over every base and field in a CXXRecordDecl and validating the constraints of the standard. This made for very straightforward code, but is extremely inefficient. It also is conceptually wrong, the logic tied to the C++ definition of standard-layout classes should be in CXXRecordDecl, not RecordType. 2) To address the performance problems with #1, a cache bit was added to CXXRecordDecl, and at the completion of every C++ class, the RecordType was queried to determine if it was a standard layout class, and that state was cached. Two things went very very wrong with this. First, the caching version of the query *was never called*. Even within the recursive steps of the walk over all fields and bases the caching variant was not called, making each query a full *recursive* walk. Second, despite the cache not being used, it was computed for every class declared, even when the trait was never used in the program. This probably significantly regressed compile time performance for edge-case files. 3) An ASTContext was required merely to query the type trait because querying it performed the actual computations. 4) The caching bit wasn't managed correctly (uninitialized). The new implementation follows the system for all the other traits on C++ classes by encoding all the state needed in the definition data and building up the trait incrementally as each base and member are added to the definition of the class. The idiosyncracies of the specification of standard-layout classes requires more state than I would like; currently 5 bits. I could eliminate one of the bits easily at the expense of both clarity and resilience of the code. I might be able to eliminate one of the other bits by computing its state in terms of other state bits in the definition. I've already done that in one place where there was a fairly simple way to achieve it. It's possible some of the bits could be moved out of the definition data and into some other structure which isn't serialized if the serialized bloat is a problem. That would preclude serialization of a partial class declaration, but that's likely already precluded. Comments on any of these issues welcome. llvm-svn: 130601
2011-04-30 17:17:45 +08:00
[AST] Cleanup comments regarding CXXRecordDecl::isEmpty We were missing references to the standard, some of our home-grown verbiage didn't make any sense. No functional change is intended. llvm-svn: 270353
2016-05-22 13:34:26 +08:00
// C++14 [meta.unary.prop]p4:
// T is a class type [...] with [...] no non-static data members other
// than bit-fields of length 0...
Centralize the management of CXXRecordDecl::DefinitionData's Empty bit in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>. This reinstates r114924, with one crucial bug fix: we were ignoring the implicit fields created by anonymous structs/unions when updating the bits in CXXRecordDecl, which means that a class/struct containing only an anonymous class/struct would be considered "empty". Hilarity follows. llvm-svn: 114980
2010-09-29 04:38:10 +08:00
if (data().Empty) {
Constant expression evaluation refactoring: - Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions, and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert behaviour. - Factor out evaluation of bitfield bit widths. - Fix a few places which would evaluate an expression twice: once to determine whether it is a constant expression, then again to get the value. llvm-svn: 141561
2011-10-11 02:28:20 +08:00
if (!Field->isBitField() ||
(!Field->getBitWidth()->isTypeDependent() &&
!Field->getBitWidth()->isValueDependent() &&
Field->getBitWidthValue(Context) != 0))
Centralize the management of CXXRecordDecl::DefinitionData's Empty bit in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>. This reinstates r114924, with one crucial bug fix: we were ignoring the implicit fields created by anonymous structs/unions when updating the bits in CXXRecordDecl, which means that a class/struct containing only an anonymous class/struct would be considered "empty". Hilarity follows. llvm-svn: 114980
2010-09-29 04:38:10 +08:00
data().Empty = false;
}
Reinstate r114921, which I've exonerated via a self-host build. Centralize the management of CXXRecordDecl::DefinitionData's Aggregate and PlainOldData bits in CXXRecordDecl itself. Another milepost on the road toward <rdar://problem/8459981>. llvm-svn: 114977
2010-09-29 03:45:33 +08:00
}
Move the management of the set of conversion functions in a C++ class into CXXRecordDecl. The only part that we do not handle this way are using declarations, since that would require extra name lookup that we don't currently want to pay for. This fixes <rdar://problem/8459981>, so that LLDB can build a CXXRecordDecl and magically get all of the right bits set. llvm-svn: 115026
2010-09-29 12:25:11 +08:00
// Handle using declarations of conversion functions.
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
if (UsingShadowDecl *Shadow = dyn_cast<UsingShadowDecl>(D)) {
Move the management of the set of conversion functions in a C++ class into CXXRecordDecl. The only part that we do not handle this way are using declarations, since that would require extra name lookup that we don't currently want to pay for. This fixes <rdar://problem/8459981>, so that LLDB can build a CXXRecordDecl and magically get all of the right bits set. llvm-svn: 115026
2010-09-29 12:25:11 +08:00
if (Shadow->getDeclName().getNameKind()
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
== DeclarationName::CXXConversionFunctionName) {
ASTContext &Ctx = getASTContext();
data().Conversions.get(Ctx).addDecl(Ctx, Shadow, Shadow->getAccess());
}
}
Add support for derived class special members hiding functions brought in from a base class via a using-declaration. If a class has a using-declaration declaring either a constructor or an assignment operator, eagerly declare its special members in case they need to displace a shadow declaration from a using-declaration. llvm-svn: 269398
2016-05-13 14:47:56 +08:00
if (UsingDecl *Using = dyn_cast<UsingDecl>(D)) {
if (Using->getDeclName().getNameKind() ==
[Sema] Don't perform aggregate initialization for types with explicit constructors Summary: The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25654 llvm-svn: 288565
2016-12-03 09:26:47 +08:00
DeclarationName::CXXConstructorName) {
Add support for derived class special members hiding functions brought in from a base class via a using-declaration. If a class has a using-declaration declaring either a constructor or an assignment operator, eagerly declare its special members in case they need to displace a shadow declaration from a using-declaration. llvm-svn: 269398
2016-05-13 14:47:56 +08:00
data().HasInheritedConstructor = true;
[Sema] Don't perform aggregate initialization for types with explicit constructors Summary: The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25654 llvm-svn: 288565
2016-12-03 09:26:47 +08:00
// C++1z [dcl.init.aggr]p1:
// An aggregate is [...] a class [...] with no inherited constructors
data().Aggregate = false;
}
Add support for derived class special members hiding functions brought in from a base class via a using-declaration. If a class has a using-declaration declaring either a constructor or an assignment operator, eagerly declare its special members in case they need to displace a shadow declaration from a using-declaration. llvm-svn: 269398
2016-05-13 14:47:56 +08:00
if (Using->getDeclName().getCXXOverloadedOperator() == OO_Equal)
data().HasInheritedAssignment = true;
}
Normalize line endings of r163013 (part 2). llvm-svn: 163032
2012-09-01 06:18:20 +08:00
}
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
void CXXRecordDecl::finishedDefaultedOrDeletedMember(CXXMethodDecl *D) {
assert(!D->isImplicit() && !D->isUserProvided());
// The kind of special member this declaration is, if any.
unsigned SMKind = 0;
if (CXXConstructorDecl *Constructor = dyn_cast<CXXConstructorDecl>(D)) {
if (Constructor->isDefaultConstructor()) {
SMKind |= SMF_DefaultConstructor;
if (Constructor->isConstexpr())
data().HasConstexprDefaultConstructor = true;
}
if (Constructor->isCopyConstructor())
SMKind |= SMF_CopyConstructor;
else if (Constructor->isMoveConstructor())
SMKind |= SMF_MoveConstructor;
else if (Constructor->isConstexpr())
// We may now know that the constructor is constexpr.
data().HasConstexprNonCopyMoveConstructor = true;
Recognize simple cases of trivial explicitly defaulted public dtors as irrelevant Reviewed in http://llvm-reviews.chandlerc.com/D3190 llvm-svn: 204953
2014-03-28 04:23:12 +08:00
} else if (isa<CXXDestructorDecl>(D)) {
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
SMKind |= SMF_Destructor;
Recognize simple cases of trivial explicitly defaulted public dtors as irrelevant Reviewed in http://llvm-reviews.chandlerc.com/D3190 llvm-svn: 204953
2014-03-28 04:23:12 +08:00
if (!D->isTrivial() || D->getAccess() != AS_public || D->isDeleted())
data().HasIrrelevantDestructor = false;
} else if (D->isCopyAssignmentOperator())
Properly compute triviality for explicitly-defaulted or deleted special members. 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
2012-12-08 10:53:02 +08:00
SMKind |= SMF_CopyAssignment;
else if (D->isMoveAssignmentOperator())
SMKind |= SMF_MoveAssignment;
// Update which trivial / non-trivial special members we have.
// addedMember will have skipped this step for this member.
if (D->isTrivial())
data().HasTrivialSpecialMembers |= SMKind;
else
data().DeclaredNonTrivialSpecialMembers |= SMKind;
}
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
void CXXRecordDecl::setTrivialForCallFlags(CXXMethodDecl *D) {
unsigned SMKind = 0;
if (CXXConstructorDecl *Constructor = dyn_cast<CXXConstructorDecl>(D)) {
if (Constructor->isCopyConstructor())
SMKind = SMF_CopyConstructor;
else if (Constructor->isMoveConstructor())
SMKind = SMF_MoveConstructor;
} else if (isa<CXXDestructorDecl>(D))
SMKind = SMF_Destructor;
if (D->isTrivialForCall())
data().HasTrivialSpecialMembersForCall |= SMKind;
else
data().DeclaredNonTrivialSpecialMembersForCall |= SMKind;
}
Normalize line endings of r163013 (part 2). llvm-svn: 163032
2012-09-01 06:18:20 +08:00
bool CXXRecordDecl::isCLike() const {
if (getTagKind() == TTK_Class || getTagKind() == TTK_Interface ||
!TemplateOrInstantiation.isNull())
return false;
if (!hasDefinition())
return true;
Introduce CXXRecordDecl::isCLike() that is true if the class is C-like, without C++-specific features. Use it to set the language to C++ when indexing non-C-like structs. rdar://10732579 llvm-svn: 148708
2012-01-24 00:58:45 +08:00
Remove redundant checks in CXXRecordDecl::isCLike(), as suggested by Sebastian. llvm-svn: 149476
2012-02-01 14:36:44 +08:00
return isPOD() && data().HasOnlyCMembers;
Introduce CXXRecordDecl::isCLike() that is true if the class is C-like, without C++-specific features. Use it to set the language to C++ when indexing non-C-like structs. rdar://10732579 llvm-svn: 148708
2012-01-24 00:58:45 +08:00
}
Refactor out the circular reference to LambdaExpr in CXXRecordDecl. A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box). Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl. In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. No change in functionality. This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): http://llvm-reviews.chandlerc.com/D1856 Thanks! llvm-svn: 193246
2013-10-24 00:10:50 +08:00
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
bool CXXRecordDecl::isGenericLambda() const {
Refactor out the circular reference to LambdaExpr in CXXRecordDecl. A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box). Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl. In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. No change in functionality. This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): http://llvm-reviews.chandlerc.com/D1856 Thanks! llvm-svn: 193246
2013-10-24 00:10:50 +08:00
if (!isLambda()) return false;
return getLambdaData().IsGenericLambda;
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
}
CXXMethodDecl* CXXRecordDecl::getLambdaCallOperator() const {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
if (!isLambda()) return nullptr;
Fix windows newlines :( llvm-svn: 191641
2013-09-30 01:08:32 +08:00
DeclarationName Name =
getASTContext().DeclarationNames.getCXXOperatorName(OO_Call);
Cleanup: remove artificial division between lookup results and const lookup results. No-one was ever modifying a lookup result, and it would not be reasonable to do so. llvm-svn: 230123
2015-02-21 10:45:19 +08:00
DeclContext::lookup_result Calls = lookup(Name);
Fix windows newlines :( llvm-svn: 191641
2013-09-30 01:08:32 +08:00
assert(!Calls.empty() && "Missing lambda call operator!");
assert(Calls.size() == 1 && "More than one lambda call operator!");
NamedDecl *CallOp = Calls.front();
if (FunctionTemplateDecl *CallOpTmpl =
dyn_cast<FunctionTemplateDecl>(CallOp))
return cast<CXXMethodDecl>(CallOpTmpl->getTemplatedDecl());
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
return cast<CXXMethodDecl>(CallOp);
}
CXXMethodDecl* CXXRecordDecl::getLambdaStaticInvoker() const {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
if (!isLambda()) return nullptr;
Fix windows newlines :( llvm-svn: 191641
2013-09-30 01:08:32 +08:00
DeclarationName Name =
&getASTContext().Idents.get(getLambdaStaticInvokerName());
Cleanup: remove artificial division between lookup results and const lookup results. No-one was ever modifying a lookup result, and it would not be reasonable to do so. llvm-svn: 230123
2015-02-21 10:45:19 +08:00
DeclContext::lookup_result Invoker = lookup(Name);
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
if (Invoker.empty()) return nullptr;
Fix windows newlines :( llvm-svn: 191641
2013-09-30 01:08:32 +08:00
assert(Invoker.size() == 1 && "More than one static invoker operator!");
NamedDecl *InvokerFun = Invoker.front();
if (FunctionTemplateDecl *InvokerTemplate =
dyn_cast<FunctionTemplateDecl>(InvokerFun))
return cast<CXXMethodDecl>(InvokerTemplate->getTemplatedDecl());
Implement conversion to function pointer for generic lambdas without captures. The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization. Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator. This patch has been reviewed in person both by Doug and Richard. Richard gave me the LGTM. A few minor changes: - per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation). - I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively. - Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker. I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming. Thanks! llvm-svn: 191634
2013-09-29 16:45:24 +08:00
return cast<CXXMethodDecl>(InvokerFun);
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
}
Extend CXXRecordDecl with a function that determines the mapping from the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
2012-02-10 15:45:31 +08:00
void CXXRecordDecl::getCaptureFields(
llvm::DenseMap<const VarDecl *, FieldDecl *> &Captures,
const-qualify CXXRecordDecl::getCaptureFields. llvm-svn: 150284
2012-02-11 08:18:00 +08:00
FieldDecl *&ThisCapture) const {
Extend CXXRecordDecl with a function that determines the mapping from the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
2012-02-10 15:45:31 +08:00
Captures.clear();
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
ThisCapture = nullptr;
Extend CXXRecordDecl with a function that determines the mapping from the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
2012-02-10 15:45:31 +08:00
Move the storage of lambda captures and capture initializers from LambdaExpr over to the CXXRecordDecl. This allows us to eliminate the back-link from the closure type to the LambdaExpr, which will simplify and lazify AST deserialization. llvm-svn: 150393
2012-02-13 23:44:47 +08:00
LambdaDefinitionData &Lambda = getLambdaData();
Extend CXXRecordDecl with a function that determines the mapping from the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
2012-02-10 15:45:31 +08:00
RecordDecl::field_iterator Field = field_begin();
Decouple ExprCXX.h and DeclCXX.h and clean up includes a bit. Required pulling LambdaExpr::Capture into its own header. No functionality change. llvm-svn: 208470
2014-05-11 00:31:55 +08:00
for (const LambdaCapture *C = Lambda.Captures, *CEnd = C + Lambda.NumCaptures;
Extend CXXRecordDecl with a function that determines the mapping from the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
2012-02-10 15:45:31 +08:00
C != CEnd; ++C, ++Field) {
First pass of semantic analysis for init-captures: check the initializer, build a FieldDecl from it, and propagate both into the closure type and the LambdaExpr. You can't do much useful with them yet -- you can't use them within the body of the lambda, because we don't have a representation for "the this of the lambda, not the this of the enclosing context". We also don't have support or a representation for a nested capture of an init-capture yet, which was intended to work despite not being allowed by the current standard wording. llvm-svn: 181985
2013-05-16 14:20:58 +08:00
if (C->capturesThis())
Revert Decl's iterators back to pointer value_type rather than reference value_type In addition, I've made the pointer and reference typedef 'void' rather than T* just so they can't get misused. I would've omitted them entirely but std::distance likes them to be there even if it doesn't use them. This rolls back r155808 and r155869. Review by Doug Gregor incorporating feedback from Chandler Carruth. llvm-svn: 158104
2012-06-07 04:45:41 +08:00
ThisCapture = *Field;
First pass of semantic analysis for init-captures: check the initializer, build a FieldDecl from it, and propagate both into the closure type and the LambdaExpr. You can't do much useful with them yet -- you can't use them within the body of the lambda, because we don't have a representation for "the this of the lambda, not the this of the enclosing context". We also don't have support or a representation for a nested capture of an init-capture yet, which was intended to work despite not being allowed by the current standard wording. llvm-svn: 181985
2013-05-16 14:20:58 +08:00
else if (C->capturesVariable())
Captures[C->getCapturedVar()] = *Field;
Extend CXXRecordDecl with a function that determines the mapping from the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
2012-02-10 15:45:31 +08:00
}
Per latest drafting, switch to implementing init-captures as if by declaring and capturing a variable declaration, and complete the implementation of them. llvm-svn: 191605
2013-09-28 12:02:39 +08:00
assert(Field == field_end());
Extend CXXRecordDecl with a function that determines the mapping from the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
2012-02-10 15:45:31 +08:00
}
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
TemplateParameterList *
CXXRecordDecl::getGenericLambdaTemplateParameterList() const {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
if (!isLambda()) return nullptr;
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
CXXMethodDecl *CallOp = getLambdaCallOperator();
if (FunctionTemplateDecl *Tmpl = CallOp->getDescribedFunctionTemplate())
return Tmpl->getTemplateParameters();
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return nullptr;
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
}
Extend CXXRecordDecl with a function that determines the mapping from the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
2012-02-10 15:45:31 +08:00
Lazily load the ContextDecl for a lambda's DefinitionData, to fix a deserialization cycle caused by the ContextDecl recursively importing members of the lambda's closure type. llvm-svn: 279694
2016-08-25 08:34:00 +08:00
Decl *CXXRecordDecl::getLambdaContextDecl() const {
assert(isLambda() && "Not a lambda closure type!");
ExternalASTSource *Source = getParentASTContext().getExternalSource();
return getLambdaData().ContextDecl.get(Source);
}
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
static CanQualType GetConversionType(ASTContext &Context, NamedDecl *Conv) {
Introduce and use Decl::getAsFunction() to simplify templated function checks Lift the getFunctionDecl() utility out of the parser into a general Decl::getAsFunction() and use it to simplify other parts of the implementation. Reduce isFunctionOrFunctionTemplate() to a simple type check that works the same was as the other is* functions and move unwrapping of shadowed decls to callers so it doesn't get run twice. Shuffle around canSkipFunctionBody() to reduce virtual dispatch on ASTConsumer. There's no need to query when we already know the body can't be skipped. llvm-svn: 199794
2014-01-22 15:29:52 +08:00
QualType T =
cast<CXXConversionDecl>(Conv->getUnderlyingDecl()->getAsFunction())
->getConversionType();
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
return Context.getCanonicalType(T);
Fixes problem in finding visible convertion functions of a class where matching conversion types in base classes were still visible. Plus refactoring and cleanup. Added a test case. llvm-svn: 83485
2009-10-08 04:43:36 +08:00
}
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
/// Collect the visible conversions of a base class.
///
Documentation cleanup: Made a parameter name in a \param command match the code llvm-svn: 158564
2012-06-16 06:28:09 +08:00
/// \param Record a base class of the class we're considering
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
/// \param InVirtual whether this base class is a virtual base (or a base
/// of a virtual base)
/// \param Access the access along the inheritance path to this base
/// \param ParentHiddenTypes the conversions provided by the inheritors
/// of this base
/// \param Output the set to which to add conversions from non-virtual bases
/// \param VOutput the set to which to add conversions from virtual bases
/// \param HiddenVBaseCs the set of conversions which were hidden in a
/// virtual base along some inheritance path
static void CollectVisibleConversions(ASTContext &Context,
CXXRecordDecl *Record,
bool InVirtual,
AccessSpecifier Access,
const llvm::SmallPtrSet<CanQualType, 8> &ParentHiddenTypes,
Introduce ASTUnresolvedSet, an UnresolvedSet-like class, whose contents are allocated using the allocator associated with an ASTContext. Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to avoid a potential memory leak. rdar://12761275 llvm-svn: 168771
2012-11-28 11:56:16 +08:00
ASTUnresolvedSet &Output,
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
UnresolvedSetImpl &VOutput,
llvm::SmallPtrSet<NamedDecl*, 8> &HiddenVBaseCs) {
// The set of types which have conversions in this class or its
// subclasses. As an optimization, we don't copy the derived set
// unless it might change.
const llvm::SmallPtrSet<CanQualType, 8> *HiddenTypes = &ParentHiddenTypes;
llvm::SmallPtrSet<CanQualType, 8> HiddenTypesBuffer;
// Collect the direct conversions and figure out which conversions
// will be hidden in the subclasses.
Don't return a pointer to an UnresolvedSetImpl in the CXXRecordDecl interface, expose only the iterators instead. llvm-svn: 168770
2012-11-28 11:56:09 +08:00
CXXRecordDecl::conversion_iterator ConvI = Record->conversion_begin();
CXXRecordDecl::conversion_iterator ConvE = Record->conversion_end();
if (ConvI != ConvE) {
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
HiddenTypesBuffer = ParentHiddenTypes;
HiddenTypes = &HiddenTypesBuffer;
Don't return a pointer to an UnresolvedSetImpl in the CXXRecordDecl interface, expose only the iterators instead. llvm-svn: 168770
2012-11-28 11:56:09 +08:00
for (CXXRecordDecl::conversion_iterator I = ConvI; I != ConvE; ++I) {
A conversion operator in a base class shouldn't hide another conversion operator in the same class, even if they convert to the same type. Fixes PR12712. llvm-svn: 156247
2012-05-06 08:04:32 +08:00
CanQualType ConvType(GetConversionType(Context, I.getDecl()));
bool Hidden = ParentHiddenTypes.count(ConvType);
if (!Hidden)
HiddenTypesBuffer.insert(ConvType);
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
// If this conversion is hidden and we're in a virtual base,
// remember that it's hidden along some inheritance path.
if (Hidden && InVirtual)
HiddenVBaseCs.insert(cast<NamedDecl>(I.getDecl()->getCanonicalDecl()));
// If this conversion isn't hidden, add it to the appropriate output.
else if (!Hidden) {
AccessSpecifier IAccess
= CXXRecordDecl::MergeAccess(Access, I.getAccess());
if (InVirtual)
VOutput.addDecl(I.getDecl(), IAccess);
More work toward having an access method for visible conversion functions. llvm-svn: 81618
2009-09-13 02:26:03 +08:00
else
Introduce ASTUnresolvedSet, an UnresolvedSet-like class, whose contents are allocated using the allocator associated with an ASTContext. Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to avoid a potential memory leak. rdar://12761275 llvm-svn: 168771
2012-11-28 11:56:16 +08:00
Output.addDecl(Context, I.getDecl(), IAccess);
Patch to build visible conversion function list lazily and make its first use in calling the conversion function on delete statements. llvm-svn: 81576
2009-09-12 05:44:33 +08:00
}
}
}
Audit the code for places where it is assumed that every base specifier refers to a RecordType. Add assertions or conditions as appropriate. This fixes another crash in the Apache stdlib vector. llvm-svn: 85055
2009-10-26 01:03:50 +08:00
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
// Collect information recursively from any base classes.
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
for (const auto &I : Record->bases()) {
const RecordType *RT = I.getType()->getAs<RecordType>();
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
if (!RT) continue;
Audit the code for places where it is assumed that every base specifier refers to a RecordType. Add assertions or conditions as appropriate. This fixes another crash in the Apache stdlib vector. llvm-svn: 85055
2009-10-26 01:03:50 +08:00
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
AccessSpecifier BaseAccess
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
= CXXRecordDecl::MergeAccess(Access, I.getAccessSpecifier());
bool BaseInVirtual = InVirtual || I.isVirtual();
Audit the code for places where it is assumed that every base specifier refers to a RecordType. Add assertions or conditions as appropriate. This fixes another crash in the Apache stdlib vector. llvm-svn: 85055
2009-10-26 01:03:50 +08:00
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
CXXRecordDecl *Base = cast<CXXRecordDecl>(RT->getDecl());
CollectVisibleConversions(Context, Base, BaseInVirtual, BaseAccess,
*HiddenTypes, Output, VOutput, HiddenVBaseCs);
Patch to build visible conversion function list lazily and make its first use in calling the conversion function on delete statements. llvm-svn: 81576
2009-09-12 05:44:33 +08:00
}
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
}
Audit the code for places where it is assumed that every base specifier refers to a RecordType. Add assertions or conditions as appropriate. This fixes another crash in the Apache stdlib vector. llvm-svn: 85055
2009-10-26 01:03:50 +08:00
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
/// Collect the visible conversions of a class.
///
/// This would be extremely straightforward if it weren't for virtual
/// bases. It might be worth special-casing that, really.
static void CollectVisibleConversions(ASTContext &Context,
CXXRecordDecl *Record,
Introduce ASTUnresolvedSet, an UnresolvedSet-like class, whose contents are allocated using the allocator associated with an ASTContext. Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to avoid a potential memory leak. rdar://12761275 llvm-svn: 168771
2012-11-28 11:56:16 +08:00
ASTUnresolvedSet &Output) {
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
// The collection of all conversions in virtual bases that we've
// found. These will be added to the output as long as they don't
// appear in the hidden-conversions set.
UnresolvedSet<8> VBaseCs;
// The set of conversions in virtual bases that we've determined to
// be hidden.
llvm::SmallPtrSet<NamedDecl*, 8> HiddenVBaseCs;
// The set of types hidden by classes derived from this one.
llvm::SmallPtrSet<CanQualType, 8> HiddenTypes;
// Go ahead and collect the direct conversions and add them to the
// hidden-types set.
Don't return a pointer to an UnresolvedSetImpl in the CXXRecordDecl interface, expose only the iterators instead. llvm-svn: 168770
2012-11-28 11:56:09 +08:00
CXXRecordDecl::conversion_iterator ConvI = Record->conversion_begin();
CXXRecordDecl::conversion_iterator ConvE = Record->conversion_end();
Introduce ASTUnresolvedSet, an UnresolvedSet-like class, whose contents are allocated using the allocator associated with an ASTContext. Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to avoid a potential memory leak. rdar://12761275 llvm-svn: 168771
2012-11-28 11:56:16 +08:00
Output.append(Context, ConvI, ConvE);
Don't return a pointer to an UnresolvedSetImpl in the CXXRecordDecl interface, expose only the iterators instead. llvm-svn: 168770
2012-11-28 11:56:09 +08:00
for (; ConvI != ConvE; ++ConvI)
HiddenTypes.insert(GetConversionType(Context, ConvI.getDecl()));
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
// Recursively collect conversions from base classes.
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
for (const auto &I : Record->bases()) {
const RecordType *RT = I.getType()->getAs<RecordType>();
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
if (!RT) continue;
CollectVisibleConversions(Context, cast<CXXRecordDecl>(RT->getDecl()),
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
I.isVirtual(), I.getAccessSpecifier(),
Remember access paths for visible conversion decls. llvm-svn: 98539
2010-03-15 17:07:48 +08:00
HiddenTypes, Output, VBaseCs, HiddenVBaseCs);
}
// Add any unhidden conversions provided by virtual bases.
for (UnresolvedSetIterator I = VBaseCs.begin(), E = VBaseCs.end();
I != E; ++I) {
if (!HiddenVBaseCs.count(cast<NamedDecl>(I.getDecl()->getCanonicalDecl())))
Introduce ASTUnresolvedSet, an UnresolvedSet-like class, whose contents are allocated using the allocator associated with an ASTContext. Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to avoid a potential memory leak. rdar://12761275 llvm-svn: 168771
2012-11-28 11:56:16 +08:00
Output.addDecl(Context, I.getDecl(), I.getAccess());
Patch to build visible conversion function list lazily and make its first use in calling the conversion function on delete statements. llvm-svn: 81576
2009-09-12 05:44:33 +08:00
}
More work toward having an access method for visible conversion functions. llvm-svn: 81618
2009-09-13 02:26:03 +08:00
}
/// getVisibleConversionFunctions - get all conversion functions visible
/// in current class; including conversion function templates.
Update APIs that return a pair of iterators to return an iterator_range instead. Convert uses of those APIs into ranged for loops. NFC. llvm-svn: 228404
2015-02-07 01:25:10 +08:00
llvm::iterator_range<CXXRecordDecl::conversion_iterator>
Don't return a pointer to an UnresolvedSetImpl in the CXXRecordDecl interface, expose only the iterators instead. llvm-svn: 168770
2012-11-28 11:56:09 +08:00
CXXRecordDecl::getVisibleConversionFunctions() {
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
ASTContext &Ctx = getASTContext();
ASTUnresolvedSet *Set;
if (bases_begin() == bases_end()) {
// If root class, all conversions are visible.
Set = &data().Conversions.get(Ctx);
} else {
Set = &data().VisibleConversions.get(Ctx);
// If visible conversion list is not evaluated, evaluate it.
if (!data().ComputedVisibleConversions) {
CollectVisibleConversions(Ctx, this, *Set);
data().ComputedVisibleConversions = true;
}
Don't return a pointer to an UnresolvedSetImpl in the CXXRecordDecl interface, expose only the iterators instead. llvm-svn: 168770
2012-11-28 11:56:09 +08:00
}
Update APIs that return a pair of iterators to return an iterator_range instead. Convert uses of those APIs into ranged for loops. NFC. llvm-svn: 228404
2015-02-07 01:25:10 +08:00
return llvm::make_range(Set->begin(), Set->end());
Patch to build visible conversion function list lazily and make its first use in calling the conversion function on delete statements. llvm-svn: 81576
2009-09-12 05:44:33 +08:00
}
Regularize support for naming conversion functions in using decls. llvm-svn: 99979
2010-03-31 09:36:47 +08:00
void CXXRecordDecl::removeConversion(const NamedDecl *ConvDecl) {
// This operation is O(N) but extremely rare. Sema only uses it to
// remove UsingShadowDecls in a class that were followed by a direct
// declaration, e.g.:
// class A : B {
// using B::operator int;
// operator int();
// };
// This is uncommon by itself and even more uncommon in conjunction
// with sufficiently large numbers of directly-declared conversions
// that asymptotic behavior matters.
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
ASTUnresolvedSet &Convs = data().Conversions.get(getASTContext());
Regularize support for naming conversion functions in using decls. llvm-svn: 99979
2010-03-31 09:36:47 +08:00
for (unsigned I = 0, E = Convs.size(); I != E; ++I) {
if (Convs[I].getDecl() == ConvDecl) {
Convs.erase(I);
assert(std::find(Convs.begin(), Convs.end(), ConvDecl) == Convs.end()
&& "conversion was found multiple times in unresolved set");
return;
}
}
Parsing, ASTs, and semantic analysis for the declaration of conversion functions in C++, e.g., struct X { operator bool() const; }; Note that these conversions don't actually do anything, since we don't yet have the ability to use them for implicit or explicit conversions. llvm-svn: 58860
2008-11-08 04:08:42 +08:00
Regularize support for naming conversion functions in using decls. llvm-svn: 99979
2010-03-31 09:36:47 +08:00
llvm_unreachable("conversion not found in set!");
Implement conversion function templates, along with the ability to use template argument deduction from a conversion function (C++ [temp.deduct.conv]) with implicit conversions. llvm-svn: 79693
2009-08-22 07:19:43 +08:00
}
Patch for implementation of C++'s object model. This is work in progress. llvm-svn: 73782
2009-06-20 03:55:27 +08:00
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
CXXRecordDecl *CXXRecordDecl::getInstantiatedFromMemberClass() const {
Diagnose the declaration of explicit specializations after an implicit instantiation has already been required. To do so, keep track of the point of instantiation for anything that can be instantiated. llvm-svn: 83890
2009-10-13 04:18:28 +08:00
if (MemberSpecializationInfo *MSInfo = getMemberSpecializationInfo())
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
return cast<CXXRecordDecl>(MSInfo->getInstantiatedFrom());
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return nullptr;
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
}
[ptr-traits] Move methods manipulating PointerUnions, DenseMap pointer keys, and PointerIntPairs where the pointee types are incomplete out-of-line to where we have the complete type. This is the standard pattern used throughout the AST library to address the inherently mutually cross referenced nature of the AST. This is part of a series of patches to allow LLVM to check for complete pointee types when computing its pointer traits. This is absolutely necessary to get correct (or reproducible) results for things like how many low bits are guaranteed to be zero. llvm-svn: 256612
2015-12-30 11:24:14 +08:00
MemberSpecializationInfo *CXXRecordDecl::getMemberSpecializationInfo() const {
return TemplateOrInstantiation.dyn_cast<MemberSpecializationInfo *>();
}
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
void
CXXRecordDecl::setInstantiationOfMemberClass(CXXRecordDecl *RD,
TemplateSpecializationKind TSK) {
assert(TemplateOrInstantiation.isNull() &&
"Previous template or instantiation?");
PR18232: implement instantiation for class-scope explicit specializations of class templates (a Microsoft extension). llvm-svn: 197298
2013-12-14 09:04:22 +08:00
assert(!isa<ClassTemplatePartialSpecializationDecl>(this));
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
TemplateOrInstantiation
= new (getASTContext()) MemberSpecializationInfo(RD, TSK);
}
[ptr-traits] Move methods manipulating PointerUnions, DenseMap pointer keys, and PointerIntPairs where the pointee types are incomplete out-of-line to where we have the complete type. This is the standard pattern used throughout the AST library to address the inherently mutually cross referenced nature of the AST. This is part of a series of patches to allow LLVM to check for complete pointee types when computing its pointer traits. This is absolutely necessary to get correct (or reproducible) results for things like how many low bits are guaranteed to be zero. llvm-svn: 256612
2015-12-30 11:24:14 +08:00
ClassTemplateDecl *CXXRecordDecl::getDescribedClassTemplate() const {
return TemplateOrInstantiation.dyn_cast<ClassTemplateDecl *>();
}
void CXXRecordDecl::setDescribedClassTemplate(ClassTemplateDecl *Template) {
TemplateOrInstantiation = Template;
}
getTemplateSpecializationKind should be const. llvm-svn: 90750
2009-12-07 14:33:48 +08:00
TemplateSpecializationKind CXXRecordDecl::getTemplateSpecializationKind() const{
if (const ClassTemplateSpecializationDecl *Spec
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
= dyn_cast<ClassTemplateSpecializationDecl>(this))
return Spec->getSpecializationKind();
Diagnose the declaration of explicit specializations after an implicit instantiation has already been required. To do so, keep track of the point of instantiation for anything that can be instantiated. llvm-svn: 83890
2009-10-13 04:18:28 +08:00
if (MemberSpecializationInfo *MSInfo = getMemberSpecializationInfo())
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
return MSInfo->getTemplateSpecializationKind();
return TSK_Undeclared;
}
void
CXXRecordDecl::setTemplateSpecializationKind(TemplateSpecializationKind TSK) {
if (ClassTemplateSpecializationDecl *Spec
= dyn_cast<ClassTemplateSpecializationDecl>(this)) {
Spec->setSpecializationKind(TSK);
return;
}
Diagnose the declaration of explicit specializations after an implicit instantiation has already been required. To do so, keep track of the point of instantiation for anything that can be instantiated. llvm-svn: 83890
2009-10-13 04:18:28 +08:00
if (MemberSpecializationInfo *MSInfo = getMemberSpecializationInfo()) {
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
MSInfo->setTemplateSpecializationKind(TSK);
return;
}
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Not a class template or member class specialization");
Improve checking for specializations of member classes of class templates, and keep track of how those member classes were instantiated or specialized. Make sure that we don't try to instantiate an explicitly-specialized member class of a class template, when that explicit specialization was a declaration rather than a definition. llvm-svn: 83547
2009-10-08 23:14:33 +08:00
}
Factor code into CXXRecordDecl::getTemplateInstantiationPattern() helper This moves some code from SemaType.cpp's hasVisibleDefinition() into DeclCXX.cpp so that it can be used elsewhere. I found one other instance of code trying to do the same thing, there are probably more. Search for getInstantiatedFrom() to try to find more. No functionality change. Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5783 llvm-svn: 219714
2014-10-15 04:28:40 +08:00
const CXXRecordDecl *CXXRecordDecl::getTemplateInstantiationPattern() const {
[modules] Properly look up the owning module for an instantiation of a merged template. When looking for the template instantiation pattern of a templated entity, consistently select the definition of the pattern if there is one. This means we'll pick the same owning module when we start instantiating a template that we'll later pick when determining which modules are visible during that instantiation. This reinstates r300650, reverted in r300659, with a fix for a regression reported by Chandler after commit. llvm-svn: 300938
2017-04-21 09:15:13 +08:00
auto GetDefinitionOrSelf =
[](const CXXRecordDecl *D) -> const CXXRecordDecl * {
if (auto *Def = D->getDefinition())
return Def;
return D;
};
Factor code into CXXRecordDecl::getTemplateInstantiationPattern() helper This moves some code from SemaType.cpp's hasVisibleDefinition() into DeclCXX.cpp so that it can be used elsewhere. I found one other instance of code trying to do the same thing, there are probably more. Search for getInstantiatedFrom() to try to find more. No functionality change. Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5783 llvm-svn: 219714
2014-10-15 04:28:40 +08:00
// If it's a class template specialization, find the template or partial
// specialization from which it was instantiated.
if (auto *TD = dyn_cast<ClassTemplateSpecializationDecl>(this)) {
auto From = TD->getInstantiatedFrom();
if (auto *CTD = From.dyn_cast<ClassTemplateDecl *>()) {
while (auto *NewCTD = CTD->getInstantiatedFromMemberTemplate()) {
if (NewCTD->isMemberSpecialization())
break;
CTD = NewCTD;
}
[modules] Properly look up the owning module for an instantiation of a merged template. When looking for the template instantiation pattern of a templated entity, consistently select the definition of the pattern if there is one. This means we'll pick the same owning module when we start instantiating a template that we'll later pick when determining which modules are visible during that instantiation. This reinstates r300650, reverted in r300659, with a fix for a regression reported by Chandler after commit. llvm-svn: 300938
2017-04-21 09:15:13 +08:00
return GetDefinitionOrSelf(CTD->getTemplatedDecl());
Factor code into CXXRecordDecl::getTemplateInstantiationPattern() helper This moves some code from SemaType.cpp's hasVisibleDefinition() into DeclCXX.cpp so that it can be used elsewhere. I found one other instance of code trying to do the same thing, there are probably more. Search for getInstantiatedFrom() to try to find more. No functionality change. Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5783 llvm-svn: 219714
2014-10-15 04:28:40 +08:00
}
if (auto *CTPSD =
From.dyn_cast<ClassTemplatePartialSpecializationDecl *>()) {
while (auto *NewCTPSD = CTPSD->getInstantiatedFromMember()) {
if (NewCTPSD->isMemberSpecialization())
break;
CTPSD = NewCTPSD;
}
[modules] Properly look up the owning module for an instantiation of a merged template. When looking for the template instantiation pattern of a templated entity, consistently select the definition of the pattern if there is one. This means we'll pick the same owning module when we start instantiating a template that we'll later pick when determining which modules are visible during that instantiation. This reinstates r300650, reverted in r300659, with a fix for a regression reported by Chandler after commit. llvm-svn: 300938
2017-04-21 09:15:13 +08:00
return GetDefinitionOrSelf(CTPSD);
Factor code into CXXRecordDecl::getTemplateInstantiationPattern() helper This moves some code from SemaType.cpp's hasVisibleDefinition() into DeclCXX.cpp so that it can be used elsewhere. I found one other instance of code trying to do the same thing, there are probably more. Search for getInstantiatedFrom() to try to find more. No functionality change. Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5783 llvm-svn: 219714
2014-10-15 04:28:40 +08:00
}
}
if (MemberSpecializationInfo *MSInfo = getMemberSpecializationInfo()) {
if (isTemplateInstantiation(MSInfo->getTemplateSpecializationKind())) {
const CXXRecordDecl *RD = this;
while (auto *NewRD = RD->getInstantiatedFromMemberClass())
RD = NewRD;
[modules] Properly look up the owning module for an instantiation of a merged template. When looking for the template instantiation pattern of a templated entity, consistently select the definition of the pattern if there is one. This means we'll pick the same owning module when we start instantiating a template that we'll later pick when determining which modules are visible during that instantiation. This reinstates r300650, reverted in r300659, with a fix for a regression reported by Chandler after commit. llvm-svn: 300938
2017-04-21 09:15:13 +08:00
return GetDefinitionOrSelf(RD);
Factor code into CXXRecordDecl::getTemplateInstantiationPattern() helper This moves some code from SemaType.cpp's hasVisibleDefinition() into DeclCXX.cpp so that it can be used elsewhere. I found one other instance of code trying to do the same thing, there are probably more. Search for getInstantiatedFrom() to try to find more. No functionality change. Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5783 llvm-svn: 219714
2014-10-15 04:28:40 +08:00
}
}
assert(!isTemplateInstantiation(this->getTemplateSpecializationKind()) &&
"couldn't find pattern for class template instantiation");
return nullptr;
}
Remove unnecessary ASTContext parameter from CXXRecordDecl::getDestructor(); no functionality change. llvm-svn: 107394
2010-07-01 22:13:13 +08:00
CXXDestructorDecl *CXXRecordDecl::getDestructor() const {
ASTContext &Context = getASTContext();
Add code for emitting C++ destructors. Not used yet. llvm-svn: 72591
2009-05-30 05:03:38 +08:00
QualType ClassType = Context.getTypeDeclType(this);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
DeclarationName Name
Introduce the canonical type smart pointers, and use them in a few places to tighten up the static type system. llvm-svn: 78164
2009-08-05 13:36:45 +08:00
= Context.DeclarationNames.getCXXDestructorName(
Context.getCanonicalType(ClassType));
Add code for emitting C++ destructors. Not used yet. llvm-svn: 72591
2009-05-30 05:03:38 +08:00
Cleanup: remove artificial division between lookup results and const lookup results. No-one was ever modifying a lookup result, and it would not be reasonable to do so. llvm-svn: 230123
2015-02-21 10:45:19 +08:00
DeclContext::lookup_result R = lookup(Name);
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix PR 33189: Clang assertion on template destructor declaration Summary: This patch aims to fix the bug reported at https://bugs.llvm.org/show_bug.cgi?id=33189. Clang hits an assertion when a template destructor declaration is present. This is caused by later processing that does not expect to encounter a template when looking at a destructor. The resolution is to treat the destructor as being not declared when later processing is interested in the properties of the destructor of a class. Reviewers: rcraik, hubert.reinterpretcast, aaron.ballman, rsmith Reviewed By: rsmith Subscribers: rsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D33833 Patch by Kuang He! llvm-svn: 306905
2017-07-01 06:43:54 +08:00
return R.empty() ? nullptr : dyn_cast<CXXDestructorDecl>(R.front());
Add code for emitting C++ destructors. Not used yet. llvm-svn: 72591
2009-05-30 05:03:38 +08:00
}
Update -Winvalid-noreturn to handle destructors better. When checking if a function is noreturn, consider a codepath to be noreturn if the path destroys a class and the class destructor, base class destructors, or member field destructors are marked noreturn. Differential Revision: http://reviews.llvm.org/D9454 llvm-svn: 238382
2015-05-28 08:14:02 +08:00
bool CXXRecordDecl::isAnyDestructorNoReturn() const {
// Destructor is noreturn.
if (const CXXDestructorDecl *Destructor = getDestructor())
if (Destructor->isNoReturn())
return true;
// Check base classes destructor for noreturn.
for (const auto &Base : bases())
Fix an assertion failure (PR33020). Adding a test separately (tools/extra/test/clang-tidy/misc-use-after-move.cpp). llvm-svn: 302889
2017-05-12 19:24:25 +08:00
if (const CXXRecordDecl *RD = Base.getType()->getAsCXXRecordDecl())
if (RD->isAnyDestructorNoReturn())
return true;
Update -Winvalid-noreturn to handle destructors better. When checking if a function is noreturn, consider a codepath to be noreturn if the path destroys a class and the class destructor, base class destructors, or member field destructors are marked noreturn. Differential Revision: http://reviews.llvm.org/D9454 llvm-svn: 238382
2015-05-28 08:14:02 +08:00
// Check fields for noreturn.
for (const auto *Field : fields())
if (const CXXRecordDecl *RD =
Field->getType()->getBaseElementTypeUnsafe()->getAsCXXRecordDecl())
if (RD->isAnyDestructorNoReturn())
return true;
// All destructors are not noreturn.
return false;
}
[Sema] Correct IUnknown to support Unknwnbase.h Header. Apparently, the MSVC SDK has a strange implementation that causes a number of implicit functions as well as a template member function of the IUnknown type. This patch allows these as InterfaceLike types as well. Additionally, it corrects the behavior where extern-C++ wrapped around an Interface-Like type would permit an interface-like type to exist in a namespace. Differential Revision: https://reviews.llvm.org/D38303 llvm-svn: 314557
2017-09-30 05:06:00 +08:00
static bool isDeclContextInNamespace(const DeclContext *DC) {
while (!DC->isTranslationUnit()) {
if (DC->isNamespace())
return true;
DC = DC->getParent();
}
return false;
}
Fix the __interface inheritence rules to work better with IUnknown and IDispatch __interface objects in MSVC are permitted to inherit from __interface types, and interface-like types. Additionally, there are two default interface-like types (IUnknown and IDispatch) that all interface-like types must inherit from. Differential Revision: https://reviews.llvm.org/D37308 llvm-svn: 313364
2017-09-16 00:03:35 +08:00
bool CXXRecordDecl::isInterfaceLike() const {
assert(hasDefinition() && "checking for interface-like without a definition");
// All __interfaces are inheritently interface-like.
if (isInterface())
return true;
// Interface-like types cannot have a user declared constructor, destructor,
// friends, VBases, conversion functions, or fields. Additionally, lambdas
// cannot be interface types.
if (isLambda() || hasUserDeclaredConstructor() ||
hasUserDeclaredDestructor() || !field_empty() || hasFriends() ||
getNumVBases() > 0 || conversion_end() - conversion_begin() > 0)
return false;
// No interface-like type can have a method with a definition.
for (const auto *const Method : methods())
[Sema] Correct IUnknown to support Unknwnbase.h Header. Apparently, the MSVC SDK has a strange implementation that causes a number of implicit functions as well as a template member function of the IUnknown type. This patch allows these as InterfaceLike types as well. Additionally, it corrects the behavior where extern-C++ wrapped around an Interface-Like type would permit an interface-like type to exist in a namespace. Differential Revision: https://reviews.llvm.org/D38303 llvm-svn: 314557
2017-09-30 05:06:00 +08:00
if (Method->isDefined() && !Method->isImplicit())
Fix the __interface inheritence rules to work better with IUnknown and IDispatch __interface objects in MSVC are permitted to inherit from __interface types, and interface-like types. Additionally, there are two default interface-like types (IUnknown and IDispatch) that all interface-like types must inherit from. Differential Revision: https://reviews.llvm.org/D37308 llvm-svn: 313364
2017-09-16 00:03:35 +08:00
return false;
// Check "Special" types.
const auto *Uuid = getAttr<UuidAttr>();
[Sema] Correct IUnknown to support Unknwnbase.h Header. Apparently, the MSVC SDK has a strange implementation that causes a number of implicit functions as well as a template member function of the IUnknown type. This patch allows these as InterfaceLike types as well. Additionally, it corrects the behavior where extern-C++ wrapped around an Interface-Like type would permit an interface-like type to exist in a namespace. Differential Revision: https://reviews.llvm.org/D38303 llvm-svn: 314557
2017-09-30 05:06:00 +08:00
// MS SDK declares IUnknown/IDispatch both in the root of a TU, or in an
// extern C++ block directly in the TU. These are only valid if in one
// of these two situations.
if (Uuid && isStruct() && !getDeclContext()->isExternCContext() &&
!isDeclContextInNamespace(getDeclContext()) &&
Fix the __interface inheritence rules to work better with IUnknown and IDispatch __interface objects in MSVC are permitted to inherit from __interface types, and interface-like types. Additionally, there are two default interface-like types (IUnknown and IDispatch) that all interface-like types must inherit from. Differential Revision: https://reviews.llvm.org/D37308 llvm-svn: 313364
2017-09-16 00:03:35 +08:00
((getName() == "IUnknown" &&
Uuid->getGuid() == "00000000-0000-0000-C000-000000000046") ||
(getName() == "IDispatch" &&
Uuid->getGuid() == "00020400-0000-0000-C000-000000000046"))) {
if (getNumBases() > 0)
return false;
return true;
}
// FIXME: Any access specifiers is supposed to make this no longer interface
// like.
// If this isn't a 'special' type, it must have a single interface-like base.
if (getNumBases() != 1)
return false;
const auto BaseSpec = *bases_begin();
if (BaseSpec.isVirtual() || BaseSpec.getAccessSpecifier() != AS_public)
return false;
const auto *Base = BaseSpec.getType()->getAsCXXRecordDecl();
if (Base->isInterface() || !Base->isInterfaceLike())
return false;
return true;
}
Revert all of my commits that devirtualized the Decl hierarchy, which lead to a serious slowdown (4%) on parsing of Cocoa.h. This memory optimization should be revisited later, when we have time to look at the generated code. llvm-svn: 126033
2011-02-20 02:51:44 +08:00
void CXXRecordDecl::completeDefinition() {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
completeDefinition(nullptr);
Revert all of my commits that devirtualized the Decl hierarchy, which lead to a serious slowdown (4%) on parsing of Cocoa.h. This memory optimization should be revisited later, when we have time to look at the generated code. llvm-svn: 126033
2011-02-20 02:51:44 +08:00
}
void CXXRecordDecl::completeDefinition(CXXFinalOverriderMap *FinalOverriders) {
RecordDecl::completeDefinition();
PR19668, PR23034: Fix handling of move constructors and deleted copy constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
2017-08-16 09:49:53 +08:00
Move the maintenance of CXXRecordDecl::DefinitionData's Abstract bit completely into CXXRecordDecl, by adding a new completeDefinition() function. This required a little reshuffling of the final-overrider checking code, since the "abstract" calculation in the presence of abstract base classes needs to occur in CXXRecordDecl::completeDefinition() but we don't want to compute final overriders more than one in the common case. llvm-svn: 115007
2010-09-29 08:15:42 +08:00
// If the class may be abstract (but hasn't been marked as such), check for
// any pure final overriders.
if (mayBeAbstract()) {
CXXFinalOverriderMap MyFinalOverriders;
if (!FinalOverriders) {
getFinalOverriders(MyFinalOverriders);
FinalOverriders = &MyFinalOverriders;
}
bool Done = false;
for (CXXFinalOverriderMap::iterator M = FinalOverriders->begin(),
MEnd = FinalOverriders->end();
M != MEnd && !Done; ++M) {
for (OverridingMethods::iterator SO = M->second.begin(),
SOEnd = M->second.end();
SO != SOEnd && !Done; ++SO) {
assert(SO->second.size() > 0 &&
"All virtual functions have overridding virtual functions");
// C++ [class.abstract]p4:
// A class is abstract if it contains or inherits at least one
// pure virtual function for which the final overrider is pure
// virtual.
if (SO->second.front().Method->isPure()) {
data().Abstract = true;
Done = true;
break;
}
}
}
}
Move the management of the set of conversion functions in a C++ class into CXXRecordDecl. The only part that we do not handle this way are using declarations, since that would require extra name lookup that we don't currently want to pay for. This fixes <rdar://problem/8459981>, so that LLDB can build a CXXRecordDecl and magically get all of the right bits set. llvm-svn: 115026
2010-09-29 12:25:11 +08:00
// Set access bits correctly on the directly-declared conversions.
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
for (conversion_iterator I = conversion_begin(), E = conversion_end();
Move the management of the set of conversion functions in a C++ class into CXXRecordDecl. The only part that we do not handle this way are using declarations, since that would require extra name lookup that we don't currently want to pay for. This fixes <rdar://problem/8459981>, so that LLDB can build a CXXRecordDecl and magically get all of the right bits set. llvm-svn: 115026
2010-09-29 12:25:11 +08:00
I != E; ++I)
Introduce ASTUnresolvedSet, an UnresolvedSet-like class, whose contents are allocated using the allocator associated with an ASTContext. Use this inside CXXRecordDecl::DefinitionData instead of an UnresolvedSet to avoid a potential memory leak. rdar://12761275 llvm-svn: 168771
2012-11-28 11:56:16 +08:00
I.setAccess((*I)->getAccess());
Move the maintenance of CXXRecordDecl::DefinitionData's Abstract bit completely into CXXRecordDecl, by adding a new completeDefinition() function. This required a little reshuffling of the final-overrider checking code, since the "abstract" calculation in the presence of abstract base classes needs to occur in CXXRecordDecl::completeDefinition() but we don't want to compute final overriders more than one in the common case. llvm-svn: 115007
2010-09-29 08:15:42 +08:00
}
bool CXXRecordDecl::mayBeAbstract() const {
if (data().Abstract || isInvalidDecl() || !data().Polymorphic ||
isDependentContext())
return false;
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
for (const auto &B : bases()) {
Move the maintenance of CXXRecordDecl::DefinitionData's Abstract bit completely into CXXRecordDecl, by adding a new completeDefinition() function. This required a little reshuffling of the final-overrider checking code, since the "abstract" calculation in the presence of abstract base classes needs to occur in CXXRecordDecl::completeDefinition() but we don't want to compute final overriders more than one in the common case. llvm-svn: 115007
2010-09-29 08:15:42 +08:00
CXXRecordDecl *BaseDecl
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
= cast<CXXRecordDecl>(B.getType()->getAs<RecordType>()->getDecl());
Move the maintenance of CXXRecordDecl::DefinitionData's Abstract bit completely into CXXRecordDecl, by adding a new completeDefinition() function. This required a little reshuffling of the final-overrider checking code, since the "abstract" calculation in the presence of abstract base classes needs to occur in CXXRecordDecl::completeDefinition() but we don't want to compute final overriders more than one in the common case. llvm-svn: 115007
2010-09-29 08:15:42 +08:00
if (BaseDecl->isAbstract())
return true;
}
return false;
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void CXXDeductionGuideDecl::anchor() {}
Add an explicit derived class of FunctionDecl to model deduction guides rather than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
2017-02-18 04:05:37 +08:00
CXXDeductionGuideDecl *CXXDeductionGuideDecl::Create(
ASTContext &C, DeclContext *DC, SourceLocation StartLoc, bool IsExplicit,
const DeclarationNameInfo &NameInfo, QualType T, TypeSourceInfo *TInfo,
SourceLocation EndLocation) {
return new (C, DC) CXXDeductionGuideDecl(C, DC, StartLoc, IsExplicit,
NameInfo, T, TInfo, EndLocation);
}
CXXDeductionGuideDecl *CXXDeductionGuideDecl::CreateDeserialized(ASTContext &C,
unsigned ID) {
return new (C, ID) CXXDeductionGuideDecl(C, nullptr, SourceLocation(), false,
DeclarationNameInfo(), QualType(),
nullptr, SourceLocation());
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void CXXMethodDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
Add 178663 back. http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green before it processed the reverted 178663, so it could not have been the culprit. Revert "Revert 178663." This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41. llvm-svn: 178682
2013-04-04 03:27:57 +08:00
bool CXXMethodDecl::isStatic() const {
Fix the storage class of method instantiations. We keep the "as written" storage class, but that is a fuzzy concept for instantiations. With this patch instantiations of methods of class templates now get a storage class that is based on the semantics of isStatic(). With this can simplify isStatic() itself. llvm-svn: 179521
2013-04-15 20:38:20 +08:00
const CXXMethodDecl *MD = getCanonicalDecl();
Add 178663 back. http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green before it processed the reverted 178663, so it could not have been the culprit. Revert "Revert 178663." This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41. llvm-svn: 178682
2013-04-04 03:27:57 +08:00
if (MD->getStorageClass() == SC_Static)
return true;
[ms-cxxabi] Fix the calling convention for operator new in records Summary: Operator new, new[], delete, and delete[] are all implicitly static when declared inside a record. CXXMethodDecl already knows this, but we need to account for that before we pick the calling convention for the function type. Fixes PR17371. Reviewers: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1761 llvm-svn: 192150
2013-10-08 08:58:57 +08:00
OverloadedOperatorKind OOK = getDeclName().getCXXOverloadedOperator();
return isStaticOverloadedOperator(OOK);
Add 178663 back. http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green before it processed the reverted 178663, so it could not have been the culprit. Revert "Revert 178663." This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41. llvm-svn: 178682
2013-04-04 03:27:57 +08:00
}
During codegen of a virtual call we would extract any casts in the expression to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
2012-06-27 01:45:31 +08:00
static bool recursivelyOverrides(const CXXMethodDecl *DerivedMD,
const CXXMethodDecl *BaseMD) {
Refactor overridden methods iteration to avoid double lookups. Convert most uses to range-for loops. No functionality change intended. llvm-svn: 320954
2017-12-18 07:52:45 +08:00
for (const CXXMethodDecl *MD : DerivedMD->overridden_methods()) {
During codegen of a virtual call we would extract any casts in the expression to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
2012-06-27 01:45:31 +08:00
if (MD->getCanonicalDecl() == BaseMD->getCanonicalDecl())
return true;
if (recursivelyOverrides(MD, BaseMD))
return true;
}
return false;
}
CXXMethodDecl *
[analyzer] Correctly devirtualize virtual method calls in constructors. This is the other half of C++11 [class.cdtor]p4 (the destructor side was added in r161915). This also fixes an issue with post-call checks where the 'this' value was already being cleaned out of the state, thus being omitted from a reconstructed CXXConstructorCall. llvm-svn: 161981
2012-08-16 04:07:17 +08:00
CXXMethodDecl::getCorrespondingMethodInClass(const CXXRecordDecl *RD,
bool MayBeBase) {
During codegen of a virtual call we would extract any casts in the expression to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
2012-06-27 01:45:31 +08:00
if (this->getParent()->getCanonicalDecl() == RD->getCanonicalDecl())
return this;
// Lookup doesn't work for destructors, so handle them separately.
if (isa<CXXDestructorDecl>(this)) {
CXXMethodDecl *MD = RD->getDestructor();
[analyzer] Correctly devirtualize virtual method calls in constructors. This is the other half of C++11 [class.cdtor]p4 (the destructor side was added in r161915). This also fixes an issue with post-call checks where the 'this' value was already being cleaned out of the state, thus being omitted from a reconstructed CXXConstructorCall. llvm-svn: 161981
2012-08-16 04:07:17 +08:00
if (MD) {
if (recursivelyOverrides(MD, this))
return MD;
if (MayBeBase && recursivelyOverrides(this, MD))
return MD;
}
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return nullptr;
During codegen of a virtual call we would extract any casts in the expression to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
2012-06-27 01:45:31 +08:00
}
Revert r167816 and replace it with a proper fix for the issue: do not invalidate lookup_iterators and lookup_results for some name within a DeclContext if the lookup results for a *different* name change. llvm-svn: 230121
2015-02-21 10:31:57 +08:00
for (auto *ND : RD->lookup(getDeclName())) {
CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(ND);
During codegen of a virtual call we would extract any casts in the expression to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
2012-06-27 01:45:31 +08:00
if (!MD)
continue;
if (recursivelyOverrides(MD, this))
return MD;
[analyzer] Correctly devirtualize virtual method calls in constructors. This is the other half of C++11 [class.cdtor]p4 (the destructor side was added in r161915). This also fixes an issue with post-call checks where the 'this' value was already being cleaned out of the state, thus being omitted from a reconstructed CXXConstructorCall. llvm-svn: 161981
2012-08-16 04:07:17 +08:00
if (MayBeBase && recursivelyOverrides(this, MD))
return MD;
During codegen of a virtual call we would extract any casts in the expression to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
2012-06-27 01:45:31 +08:00
}
[C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
2014-03-13 23:41:46 +08:00
for (const auto &I : RD->bases()) {
const RecordType *RT = I.getType()->getAs<RecordType>();
During codegen of a virtual call we would extract any casts in the expression to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
2012-06-27 01:45:31 +08:00
if (!RT)
continue;
const CXXRecordDecl *Base = cast<CXXRecordDecl>(RT->getDecl());
CXXMethodDecl *T = this->getCorrespondingMethodInClass(Base);
if (T)
return T;
}
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return nullptr;
During codegen of a virtual call we would extract any casts in the expression to see if we had an underlying final class or method, but we would then use the cast type to do the call, resulting in a direct call to the wrong method. llvm-svn: 159212
2012-06-27 01:45:31 +08:00
}
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
CXXMethodDecl *
CXXMethodDecl::Create(ASTContext &C, CXXRecordDecl *RD,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
SourceLocation StartLoc,
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
const DeclarationNameInfo &NameInfo,
DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated variables, but the results are imperfect. For posterity, I did: cat <<EOF > $cmdfile s/DeclaratorInfo/TypeSourceInfo/g s/DInfo/TInfo/g s/TypeTypeSourceInfo/TypeSourceInfo/g s/SourceTypeSourceInfo/TypeSourceInfo/g EOF find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \; find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \; find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \; llvm-svn: 90743
2009-12-07 10:54:59 +08:00
QualType T, TypeSourceInfo *TInfo,
Add 178663 back. http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green before it processed the reverted 178663, so it could not have been the culprit. Revert "Revert 178663." This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41. llvm-svn: 178682
2013-04-04 03:27:57 +08:00
StorageClass SC, bool isInline,
Track in the AST whether a function is constexpr. llvm-svn: 137653
2011-08-16 05:04:07 +08:00
bool isConstexpr, SourceLocation EndLocation) {
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
return new (C, RD) CXXMethodDecl(CXXMethod, C, RD, StartLoc, NameInfo,
T, TInfo, SC, isInline, isConstexpr,
EndLocation);
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
}
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
CXXMethodDecl *CXXMethodDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
return new (C, ID) CXXMethodDecl(CXXMethod, C, nullptr, SourceLocation(),
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
DeclarationNameInfo(), QualType(), nullptr,
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
SC_None, false, false, SourceLocation());
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
[Sema] Mark a virtual CXXMethodDecl as used if a call to it can be devirtualized. The code to detect devirtualized calls is already in IRGen, so move the code to lib/AST and make it a shared utility between Sema and IRGen. This commit fixes a linkage error I was seeing when compiling the following code: $ cat test1.cpp struct Base { virtual void operator()() {} }; template<class T> struct Derived final : Base { void operator()() override {} }; Derived<int> *d; int main() { if (d) (*d)(); return 0; } rdar://problem/33195657 Differential Revision: https://reviews.llvm.org/D34301 llvm-svn: 307883
2017-07-13 14:08:27 +08:00
CXXMethodDecl *CXXMethodDecl::getDevirtualizedMethod(const Expr *Base,
bool IsAppleKext) {
assert(isVirtual() && "this method is expected to be virtual");
// When building with -fapple-kext, all calls must go through the vtable since
// the kernel linker can do runtime patching of vtables.
if (IsAppleKext)
return nullptr;
// If the member function is marked 'final', we know that it can't be
// overridden and can therefore devirtualize it unless it's pure virtual.
if (hasAttr<FinalAttr>())
return isPure() ? nullptr : this;
// If Base is unknown, we cannot devirtualize.
if (!Base)
return nullptr;
// If the base expression (after skipping derived-to-base conversions) is a
// class prvalue, then we can devirtualize.
Base = Base->getBestDynamicClassTypeExpr();
if (Base->isRValue() && Base->getType()->isRecordType())
return this;
// If we don't even know what we would call, we can't devirtualize.
const CXXRecordDecl *BestDynamicDecl = Base->getBestDynamicClassType();
if (!BestDynamicDecl)
return nullptr;
// There may be a method corresponding to MD in a derived class.
CXXMethodDecl *DevirtualizedMethod =
getCorrespondingMethodInClass(BestDynamicDecl);
// If that method is pure virtual, we can't devirtualize. If this code is
// reached, the result would be UB, not a direct call to the derived class
// function, and we can't assume the derived class function is defined.
if (DevirtualizedMethod->isPure())
return nullptr;
// If that method is marked final, we can devirtualize it.
if (DevirtualizedMethod->hasAttr<FinalAttr>())
return DevirtualizedMethod;
// Similarly, if the class itself is marked 'final' it can't be overridden
// and we can therefore devirtualize the member function call.
if (BestDynamicDecl->hasAttr<FinalAttr>())
return DevirtualizedMethod;
if (const DeclRefExpr *DRE = dyn_cast<DeclRefExpr>(Base)) {
if (const VarDecl *VD = dyn_cast<VarDecl>(DRE->getDecl()))
if (VD->getType()->isRecordType())
// This is a record decl. We know the type and can devirtualize it.
return DevirtualizedMethod;
return nullptr;
}
// We can devirtualize calls on an object accessed by a class member access
// expression, since by C++11 [basic.life]p6 we know that it can't refer to
// a derived class object constructed in the same location.
if (const MemberExpr *ME = dyn_cast<MemberExpr>(Base))
if (const ValueDecl *VD = dyn_cast<ValueDecl>(ME->getMemberDecl()))
return VD->getType()->isRecordType() ? DevirtualizedMethod : nullptr;
// Likewise for calls on an object accessed by a (non-reference) pointer to
// member access.
if (auto *BO = dyn_cast<BinaryOperator>(Base)) {
if (BO->isPtrMemOp()) {
auto *MPT = BO->getRHS()->getType()->castAs<MemberPointerType>();
if (MPT->getPointeeType()->isRecordType())
return DevirtualizedMethod;
}
}
// We can't devirtualize the call.
return nullptr;
}
Handle C++ delete expressions when the overloaded delete operator is a "usual deallocation function" with two arguments. CodeGen will have to handle this case specifically, since the value for the second argument (the size of the allocated object) may have to be computed at run time. Fixes the Sema part of PR4782. llvm-svn: 83080
2009-09-30 02:16:17 +08:00
bool CXXMethodDecl::isUsualDeallocationFunction() const {
if (getOverloadedOperator() != OO_Delete &&
getOverloadedOperator() != OO_Array_Delete)
return false;
Implement semantic analysis for C++ [expr.new]p18-20, which describe how we find the operator delete that matches withe operator new we found in a C++ new-expression. This will also need CodeGen support. On a happy note, we're now a "nans" away from building tramp3d-v4. llvm-svn: 97209
2010-02-26 13:06:18 +08:00
// C++ [basic.stc.dynamic.deallocation]p2:
// A template instance is never a usual deallocation function,
// regardless of its signature.
if (getPrimaryTemplate())
return false;
Handle C++ delete expressions when the overloaded delete operator is a "usual deallocation function" with two arguments. CodeGen will have to handle this case specifically, since the value for the second argument (the size of the allocated object) may have to be computed at run time. Fixes the Sema part of PR4782. llvm-svn: 83080
2009-09-30 02:16:17 +08:00
// C++ [basic.stc.dynamic.deallocation]p2:
// If a class T has a member deallocation function named operator delete
// with exactly one parameter, then that function is a usual (non-placement)
// deallocation function. [...]
if (getNumParams() == 1)
return true;
Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use of past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
2016-10-11 02:54:32 +08:00
unsigned UsualParams = 1;
P0035R4: add std::align_val_t overloads of operator new/delete in C++17 mode. llvm-svn: 282800
2016-09-30 06:49:46 +08:00
Support for destroying operator delete, per C++2a proposal P0722. This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
2017-10-13 09:55:36 +08:00
// C++ P0722:
// A destroying operator delete is a usual deallocation function if
// removing the std::destroying_delete_t parameter and changing the
// first parameter type from T* to void* results in the signature of
// a usual deallocation function.
if (isDestroyingOperatorDelete())
++UsualParams;
Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use of past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
2016-10-11 02:54:32 +08:00
// C++ <=14 [basic.stc.dynamic.deallocation]p2:
Handle C++ delete expressions when the overloaded delete operator is a "usual deallocation function" with two arguments. CodeGen will have to handle this case specifically, since the value for the second argument (the size of the allocated object) may have to be computed at run time. Fixes the Sema part of PR4782. llvm-svn: 83080
2009-09-30 02:16:17 +08:00
// [...] If class T does not declare such an operator delete but does
// declare a member deallocation function named operator delete with
// exactly two parameters, the second of which has type std::size_t (18.1),
// then this function is a usual deallocation function.
Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use of past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
2016-10-11 02:54:32 +08:00
//
// C++17 says a usual deallocation function is one with the signature
// (void* [, size_t] [, std::align_val_t] [, ...])
// and all such functions are usual deallocation functions. It's not clear
// that allowing varargs functions was intentional.
Handle C++ delete expressions when the overloaded delete operator is a "usual deallocation function" with two arguments. CodeGen will have to handle this case specifically, since the value for the second argument (the size of the allocated object) may have to be computed at run time. Fixes the Sema part of PR4782. llvm-svn: 83080
2009-09-30 02:16:17 +08:00
ASTContext &Context = getASTContext();
Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use of past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
2016-10-11 02:54:32 +08:00
if (UsualParams < getNumParams() &&
Context.hasSameUnqualifiedType(getParamDecl(UsualParams)->getType(),
Context.getSizeType()))
++UsualParams;
if (UsualParams < getNumParams() &&
getParamDecl(UsualParams)->getType()->isAlignValT())
++UsualParams;
if (UsualParams != getNumParams())
Handle C++ delete expressions when the overloaded delete operator is a "usual deallocation function" with two arguments. CodeGen will have to handle this case specifically, since the value for the second argument (the size of the allocated object) may have to be computed at run time. Fixes the Sema part of PR4782. llvm-svn: 83080
2009-09-30 02:16:17 +08:00
return false;
Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use of past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
2016-10-11 02:54:32 +08:00
// In C++17 onwards, all potential usual deallocation functions are actual
// usual deallocation functions.
if (Context.getLangOpts().AlignedAllocation)
return true;
Handle C++ delete expressions when the overloaded delete operator is a "usual deallocation function" with two arguments. CodeGen will have to handle this case specifically, since the value for the second argument (the size of the allocated object) may have to be computed at run time. Fixes the Sema part of PR4782. llvm-svn: 83080
2009-09-30 02:16:17 +08:00
// This function is a usual deallocation function if there are no
// single-parameter deallocation functions of the same kind.
Cleanup: remove artificial division between lookup results and const lookup results. No-one was ever modifying a lookup result, and it would not be reasonable to do so. llvm-svn: 230123
2015-02-21 10:45:19 +08:00
DeclContext::lookup_result R = getDeclContext()->lookup(getDeclName());
for (DeclContext::lookup_result::iterator I = R.begin(), E = R.end();
Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as per review discussion in r170365 This does limit these typedefs to being sequences, but no current usage requires them to be contiguous (we could expand this to a more general iterator pair range concept at some point). Also, it'd be nice if SmallVector were constructible directly from an ArrayRef but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the inverse conversion. (& generalizing over all range-like things, while nice, would require some nontrivial SFINAE I haven't thought about yet) llvm-svn: 170482
2012-12-19 08:45:41 +08:00
I != E; ++I) {
if (const FunctionDecl *FD = dyn_cast<FunctionDecl>(*I))
Handle C++ delete expressions when the overloaded delete operator is a "usual deallocation function" with two arguments. CodeGen will have to handle this case specifically, since the value for the second argument (the size of the allocated object) may have to be computed at run time. Fixes the Sema part of PR4782. llvm-svn: 83080
2009-09-30 02:16:17 +08:00
if (FD->getNumParams() == 1)
return false;
}
return true;
}
Complete reimplementation of the synthesis for implicitly-defined copy assignment operators. Previously, Sema provided type-checking and template instantiation for copy assignment operators, then CodeGen would synthesize the actual body of the copy constructor. Unfortunately, the two were not in sync, and CodeGen might pick a copy-assignment operator that is different from what Sema chose, leading to strange failures, e.g., link-time failures when CodeGen called a copy-assignment operator that was not instantiation, run-time failures when copy-assignment operators were overloaded for const/non-const references and the wrong one was picked, and run-time failures when by-value copy-assignment operators did not have their arguments properly copy-initialized. This implementation synthesizes the implicitly-defined copy assignment operator bodies in Sema, so that the resulting ASTs encode exactly what CodeGen needs to do; there is no longer any special code in CodeGen to synthesize copy-assignment operators. The synthesis of the body is relatively simple, and we generate one of three different kinds of copy statements for each base or member: - For a class subobject, call the appropriate copy-assignment operator, after overload resolution has determined what that is. - For an array of scalar types or an array of class types that have trivial copy assignment operators, construct a call to __builtin_memcpy. - For an array of class types with non-trivial copy assignment operators, synthesize a (possibly nested!) for loop whose inner statement calls the copy constructor. - For a scalar type, use built-in assignment. This patch fixes at least a few tests cases in Boost.Spirit that were failing because CodeGen picked the wrong copy-assignment operator (leading to link-time failures), and I suspect a number of undiagnosed problems will also go away with this change. Some of the diagnostics we had previously have gotten worse with this change, since we're going through generic code for our type-checking. I will improve this in a subsequent patch. llvm-svn: 102853
2010-05-02 04:49:11 +08:00
bool CXXMethodDecl::isCopyAssignmentOperator() const {
Implement a little bit of cleanup and a lot more of the base work behind implicit moves. We now correctly identify move constructors and assignment operators and update bits on the record correctly. Generation of implicit moves (declarations or definitions) is not yet supported. llvm-svn: 132080
2011-05-26 04:50:04 +08:00
// C++0x [class.copy]p17:
Complete reimplementation of the synthesis for implicitly-defined copy assignment operators. Previously, Sema provided type-checking and template instantiation for copy assignment operators, then CodeGen would synthesize the actual body of the copy constructor. Unfortunately, the two were not in sync, and CodeGen might pick a copy-assignment operator that is different from what Sema chose, leading to strange failures, e.g., link-time failures when CodeGen called a copy-assignment operator that was not instantiation, run-time failures when copy-assignment operators were overloaded for const/non-const references and the wrong one was picked, and run-time failures when by-value copy-assignment operators did not have their arguments properly copy-initialized. This implementation synthesizes the implicitly-defined copy assignment operator bodies in Sema, so that the resulting ASTs encode exactly what CodeGen needs to do; there is no longer any special code in CodeGen to synthesize copy-assignment operators. The synthesis of the body is relatively simple, and we generate one of three different kinds of copy statements for each base or member: - For a class subobject, call the appropriate copy-assignment operator, after overload resolution has determined what that is. - For an array of scalar types or an array of class types that have trivial copy assignment operators, construct a call to __builtin_memcpy. - For an array of class types with non-trivial copy assignment operators, synthesize a (possibly nested!) for loop whose inner statement calls the copy constructor. - For a scalar type, use built-in assignment. This patch fixes at least a few tests cases in Boost.Spirit that were failing because CodeGen picked the wrong copy-assignment operator (leading to link-time failures), and I suspect a number of undiagnosed problems will also go away with this change. Some of the diagnostics we had previously have gotten worse with this change, since we're going through generic code for our type-checking. I will improve this in a subsequent patch. llvm-svn: 102853
2010-05-02 04:49:11 +08:00
// A user-declared copy assignment operator X::operator= is a non-static
// non-template member function of class X with exactly one parameter of
// type X, X&, const X&, volatile X& or const volatile X&.
if (/*operator=*/getOverloadedOperator() != OO_Equal ||
/*non-static*/ isStatic() ||
Fix crash on zero-argument assignment operator. Make sure we don't crash when checking whether an assignment operator without any arguments is a special member. <rdar://problem/14397774>. llvm-svn: 186137
2013-07-12 07:55:07 +08:00
/*non-template*/getPrimaryTemplate() || getDescribedFunctionTemplate() ||
getNumParams() != 1)
Complete reimplementation of the synthesis for implicitly-defined copy assignment operators. Previously, Sema provided type-checking and template instantiation for copy assignment operators, then CodeGen would synthesize the actual body of the copy constructor. Unfortunately, the two were not in sync, and CodeGen might pick a copy-assignment operator that is different from what Sema chose, leading to strange failures, e.g., link-time failures when CodeGen called a copy-assignment operator that was not instantiation, run-time failures when copy-assignment operators were overloaded for const/non-const references and the wrong one was picked, and run-time failures when by-value copy-assignment operators did not have their arguments properly copy-initialized. This implementation synthesizes the implicitly-defined copy assignment operator bodies in Sema, so that the resulting ASTs encode exactly what CodeGen needs to do; there is no longer any special code in CodeGen to synthesize copy-assignment operators. The synthesis of the body is relatively simple, and we generate one of three different kinds of copy statements for each base or member: - For a class subobject, call the appropriate copy-assignment operator, after overload resolution has determined what that is. - For an array of scalar types or an array of class types that have trivial copy assignment operators, construct a call to __builtin_memcpy. - For an array of class types with non-trivial copy assignment operators, synthesize a (possibly nested!) for loop whose inner statement calls the copy constructor. - For a scalar type, use built-in assignment. This patch fixes at least a few tests cases in Boost.Spirit that were failing because CodeGen picked the wrong copy-assignment operator (leading to link-time failures), and I suspect a number of undiagnosed problems will also go away with this change. Some of the diagnostics we had previously have gotten worse with this change, since we're going through generic code for our type-checking. I will improve this in a subsequent patch. llvm-svn: 102853
2010-05-02 04:49:11 +08:00
return false;
QualType ParamType = getParamDecl(0)->getType();
if (const LValueReferenceType *Ref = ParamType->getAs<LValueReferenceType>())
ParamType = Ref->getPointeeType();
ASTContext &Context = getASTContext();
QualType ClassType
= Context.getCanonicalType(Context.getTypeDeclType(getParent()));
return Context.hasSameUnqualifiedType(ClassType, ParamType);
}
Implement a little bit of cleanup and a lot more of the base work behind implicit moves. We now correctly identify move constructors and assignment operators and update bits on the record correctly. Generation of implicit moves (declarations or definitions) is not yet supported. llvm-svn: 132080
2011-05-26 04:50:04 +08:00
bool CXXMethodDecl::isMoveAssignmentOperator() const {
// C++0x [class.copy]p19:
// A user-declared move assignment operator X::operator= is a non-static
// non-template member function of class X with exactly one parameter of type
// X&&, const X&&, volatile X&&, or const volatile X&&.
if (getOverloadedOperator() != OO_Equal || isStatic() ||
Fix crash on zero-argument assignment operator. Make sure we don't crash when checking whether an assignment operator without any arguments is a special member. <rdar://problem/14397774>. llvm-svn: 186137
2013-07-12 07:55:07 +08:00
getPrimaryTemplate() || getDescribedFunctionTemplate() ||
getNumParams() != 1)
Implement a little bit of cleanup and a lot more of the base work behind implicit moves. We now correctly identify move constructors and assignment operators and update bits on the record correctly. Generation of implicit moves (declarations or definitions) is not yet supported. llvm-svn: 132080
2011-05-26 04:50:04 +08:00
return false;
QualType ParamType = getParamDecl(0)->getType();
if (!isa<RValueReferenceType>(ParamType))
return false;
ParamType = ParamType->getPointeeType();
ASTContext &Context = getASTContext();
QualType ClassType
= Context.getCanonicalType(Context.getTypeDeclType(getParent()));
return Context.hasSameUnqualifiedType(ClassType, ParamType);
}
Add setters/getters to CXXMethodDecl so it can keep track of which virtual member functions it overrides (if any) llvm-svn: 71968
2009-05-17 07:58:37 +08:00
void CXXMethodDecl::addOverriddenMethod(const CXXMethodDecl *MD) {
Make sure that overridden method decls are always canonical. llvm-svn: 90542
2009-12-04 13:51:56 +08:00
assert(MD->isCanonicalDecl() && "Method is not canonical!");
Add an assert to make sure that we don't try to mess with overridden methods for class templates. llvm-svn: 94907
2010-01-31 01:42:34 +08:00
assert(!MD->getParent()->isDependentContext() &&
"Can't add an overridden method to a class template!");
Make sure the accessors for overridden methods don't return inherited constructors. Fixes PR12219. llvm-svn: 152470
2012-03-10 09:39:01 +08:00
assert(MD->isVirtual() && "Method is not virtual!");
Add an assert to make sure that we don't try to mess with overridden methods for class templates. llvm-svn: 94907
2010-01-31 01:42:34 +08:00
Eliminate the static map of overridden C++ methods, which was going to come back to bite us at some point. llvm-svn: 97607
2010-03-03 07:58:15 +08:00
getASTContext().addOverriddenMethod(this, MD);
Add setters/getters to CXXMethodDecl so it can keep track of which virtual member functions it overrides (if any) llvm-svn: 71968
2009-05-17 07:58:37 +08:00
}
CXXMethodDecl::method_iterator CXXMethodDecl::begin_overridden_methods() const {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
if (isa<CXXConstructorDecl>(this)) return nullptr;
Eliminate the static map of overridden C++ methods, which was going to come back to bite us at some point. llvm-svn: 97607
2010-03-03 07:58:15 +08:00
return getASTContext().overridden_methods_begin(this);
Add setters/getters to CXXMethodDecl so it can keep track of which virtual member functions it overrides (if any) llvm-svn: 71968
2009-05-17 07:58:37 +08:00
}
CXXMethodDecl::method_iterator CXXMethodDecl::end_overridden_methods() const {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
if (isa<CXXConstructorDecl>(this)) return nullptr;
Eliminate the static map of overridden C++ methods, which was going to come back to bite us at some point. llvm-svn: 97607
2010-03-03 07:58:15 +08:00
return getASTContext().overridden_methods_end(this);
Add setters/getters to CXXMethodDecl so it can keep track of which virtual member functions it overrides (if any) llvm-svn: 71968
2009-05-17 07:58:37 +08:00
}
Read/write more information of ASTContext for PCH. Overriden methods and instantiated-from information. llvm-svn: 107597
2010-07-05 05:44:35 +08:00
unsigned CXXMethodDecl::size_overridden_methods() const {
Make sure the accessors for overridden methods don't return inherited constructors. Fixes PR12219. llvm-svn: 152470
2012-03-10 09:39:01 +08:00
if (isa<CXXConstructorDecl>(this)) return 0;
Read/write more information of ASTContext for PCH. Overriden methods and instantiated-from information. llvm-svn: 107597
2010-07-05 05:44:35 +08:00
return getASTContext().overridden_methods_size(this);
}
[ASTMatchers] New forEachOverriden matcher. Matches methods overridden by the given method. llvm-svn: 274531
2016-07-05 15:49:31 +08:00
CXXMethodDecl::overridden_method_range
CXXMethodDecl::overridden_methods() const {
if (isa<CXXConstructorDecl>(this))
return overridden_method_range(nullptr, nullptr);
return getASTContext().overridden_methods(this);
}
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
QualType CXXMethodDecl::getThisType(ASTContext &C) const {
Add a quote from the standard about the type of 'this'. llvm-svn: 58124
2008-10-25 06:28:18 +08:00
// C++ 9.3.2p1: The type of this in a member function of a class X is X*.
// If the member function is declared const, the type of this is const X*,
// if the member function is declared volatile, the type of this is
// volatile X*, and if the member function is declared const volatile,
// the type of this is const volatile X*.
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
assert(isInstance() && "No 'this' for static methods!");
If a CXXRecordDecl is a class template, the 'this' type should be the injected class name type. Fixes pr4383. llvm-svn: 73284
2009-06-13 10:59:33 +08:00
Create a new InjectedClassNameType to represent bare-word references to the injected class name of a class template or class template partial specialization. This is a non-canonical type; the canonical type is still a template specialization type. This becomes the TypeForDecl of the pattern declaration, which cleans up some amount of code (and complicates some other parts, but whatever). Fixes PR6326 and probably a few others, primarily by re-establishing a few invariants about TypeLoc sizes. llvm-svn: 98134
2010-03-10 11:28:59 +08:00
QualType ClassTy = C.getTypeDeclType(getParent());
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
ClassTy = C.getQualifiedType(ClassTy,
[MSVC] Support for __unaligned qualifier in functions This implements support for MS-specific __unaligned qualifier in functions and makes the following test case both compile and mangle correctly: struct S { void f() __unaligned; }; void S::f() __unaligned { } Differential Revision: http://reviews.llvm.org/D20437 llvm-svn: 270834
2016-05-26 18:06:01 +08:00
Qualifiers::fromCVRUMask(getTypeQualifiers()));
Fix type of 'this' and add a decltype test. llvm-svn: 75291
2009-07-11 05:35:09 +08:00
return C.getPointerType(ClassTy);
Change struct forward declarations and definitions to use unique RecordDecls, as opposed to creating a single RecordDecl and reusing it. This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet). The motivation of this patch is as follows: - Capture more source information, necessary for refactoring/rewriting clients. - Pave the way to resolve ownership issues with RecordDecls with the forthcoming addition of DeclGroups. Current caveats: - Until DeclGroups are in place, we will leak RecordDecls not explicitly referenced by the AST. For example: typedef struct { ... } x; The RecordDecl for the struct will be leaked because the TypedefDecl doesn't refer to it. This will be solved with DeclGroups. - This patch also (temporarily) breaks CodeGen. More below. High-level changes: - As before, TagType still refers to a TagDecl, but it doesn't own it. When a struct/union/class is first referenced, a RecordType and RecordDecl are created for it, and the RecordType refers to that RecordDecl. Later, if a new RecordDecl is created, the pointer to a RecordDecl in RecordType is updated to point to the RecordDecl that defines the struct/union/class. - TagDecl and RecordDecl now how a method 'getDefinition()' to return the TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular enum/struct/class/union. This is useful from going from a RecordDecl* that defines a forward declaration to the RecordDecl* that provides the actual definition. Note that this also works for EnumDecls, except that in this case there is no distinction between forward declarations and definitions (yet). - Clients should no longer assume that 'isDefinition()' returns true from a RecordDecl if the corresponding struct/union/class has been defined. isDefinition() only returns true if a particular RecordDecl is the defining Decl. Use 'getDefinition()' instead to determine if a struct has been defined. - The main changes to Sema happen in ActOnTag. To make the changes more incremental, I split off the processing of enums and structs et al into two code paths. Enums use the original code path (which is in ActOnTag) and structs use the ActOnTagStruct. Eventually the two code paths will be merged, but the idea was to preserve the original logic both for comparison and not to change the logic for both enums and structs all at once. - There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls that correspond to the same type simply have a pointer to that type. If we need to figure out what are all the RecordDecls for a given type we can build a backmap. - The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the changes to RecordDecl. For some reason 'svn' marks the entire file as changed. Why is CodeGen broken: - Codegen assumes that there is an equivalence between RecordDecl* and RecordType*. This was true before because we only created one RecordDecl* for a given RecordType*, but it is no longer true. I believe this shouldn't be too hard to change, but the patch was big enough as it is. I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C). llvm-svn: 55839
2008-09-06 01:16:31 +08:00
}
Move helper onto CXXMethodDecl. llvm-svn: 90716
2009-12-07 04:50:05 +08:00
bool CXXMethodDecl::hasInlineBody() const {
Improve key-function computation for templates. In particular: - All classes can have a key function; templates don't change that. non-template classes when computing the key function. - We always mark all of the virtual member functions of class template instantiations. - The vtable for an instantiation of a class template has weak linkage. We could probably use available_externally linkage for vtables of classes instantiated by explicit instantiation declarations (extern templates), but GCC doesn't do this and I'm not 100% that the ABI permits it. llvm-svn: 92753
2010-01-06 03:06:31 +08:00
// If this function is a template instantiation, look at the template from
// which it was instantiated.
const FunctionDecl *CheckFn = getTemplateInstantiationPattern();
if (!CheckFn)
CheckFn = this;
PR34163: Don't cache an incorrect key function for a class if queried between the class becoming complete and its inline methods being parsed. This replaces the hack of using the "late parsed template" flag to track member functions with bodies we've not parsed yet; instead we now use the "will have body" flag, which carries the desired implication that the function declaration *is* a definition, and that we've just not parsed its body yet. llvm-svn: 310776
2017-08-12 09:46:03 +08:00
Move helper onto CXXMethodDecl. llvm-svn: 90716
2009-12-07 04:50:05 +08:00
const FunctionDecl *fn;
PR34163: Don't cache an incorrect key function for a class if queried between the class becoming complete and its inline methods being parsed. This replaces the hack of using the "late parsed template" flag to track member functions with bodies we've not parsed yet; instead we now use the "will have body" flag, which carries the desired implication that the function declaration *is* a definition, and that we've just not parsed its body yet. llvm-svn: 310776
2017-08-12 09:46:03 +08:00
return CheckFn->isDefined(fn) && !fn->isOutOfLine() &&
(fn->doesThisDeclarationHaveABody() || fn->willHaveBody());
Move helper onto CXXMethodDecl. llvm-svn: 90716
2009-12-07 04:50:05 +08:00
}
Rework the Sema/AST/IRgen dance for the lambda closure type's conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
2012-02-17 11:02:34 +08:00
bool CXXMethodDecl::isLambdaStaticInvoker() const {
Implement conversion to function pointer for generic lambdas without captures. The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization. Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator. This patch has been reviewed in person both by Doug and Richard. Richard gave me the LGTM. A few minor changes: - per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation). - I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively. - Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker. I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming. Thanks! llvm-svn: 191634
2013-09-29 16:45:24 +08:00
const CXXRecordDecl *P = getParent();
if (P->isLambda()) {
if (const CXXMethodDecl *StaticInvoker = P->getLambdaStaticInvoker()) {
if (StaticInvoker == this) return true;
if (P->isGenericLambda() && this->isFunctionTemplateSpecialization())
return StaticInvoker == this->getPrimaryTemplate()->getTemplatedDecl();
}
}
return false;
Rework the Sema/AST/IRgen dance for the lambda closure type's conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
2012-02-17 11:02:34 +08:00
}
Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter, more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
2011-01-09 04:30:50 +08:00
CXXCtorInitializer::CXXCtorInitializer(ASTContext &Context,
TypeSourceInfo *TInfo, bool IsVirtual,
SourceLocation L, Expr *Init,
SourceLocation R,
SourceLocation EllipsisLoc)
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
: Initializee(TInfo), MemberOrEllipsisLocation(EllipsisLoc), Init(Init),
LParenLoc(L), RParenLoc(R), IsDelegating(false), IsVirtual(IsVirtual),
IsWritten(false), SourceOrder(0) {}
Initial implementation of parsing, semantic analysis, and AST-building for constructor initializations, e.g., class A { }; class B : public A { int m; public: B() : A(), m(17) { }; }; llvm-svn: 58749
2008-11-05 12:29:56 +08:00
Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter, more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
2011-01-09 04:30:50 +08:00
CXXCtorInitializer::CXXCtorInitializer(ASTContext &Context,
FieldDecl *Member,
SourceLocation MemberLoc,
SourceLocation L, Expr *Init,
SourceLocation R)
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
: Initializee(Member), MemberOrEllipsisLocation(MemberLoc), Init(Init),
LParenLoc(L), RParenLoc(R), IsDelegating(false), IsVirtual(false),
IsWritten(false), SourceOrder(0) {}
More anonymous struct/union redesign. This one deals with anonymous field used in a constructor initializer list: struct X { X() : au_i1(123) {} union { int au_i1; float au_f1; }; }; clang will now deal with au_i1 explicitly as an IndirectFieldDecl. llvm-svn: 120900
2010-12-04 17:14:42 +08:00
Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter, more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
2011-01-09 04:30:50 +08:00
CXXCtorInitializer::CXXCtorInitializer(ASTContext &Context,
IndirectFieldDecl *Member,
SourceLocation MemberLoc,
SourceLocation L, Expr *Init,
SourceLocation R)
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
: Initializee(Member), MemberOrEllipsisLocation(MemberLoc), Init(Init),
LParenLoc(L), RParenLoc(R), IsDelegating(false), IsVirtual(false),
IsWritten(false), SourceOrder(0) {}
Initial implementation of parsing, semantic analysis, and AST-building for constructor initializations, e.g., class A { }; class B : public A { int m; public: B() : A(), m(17) { }; }; llvm-svn: 58749
2008-11-05 12:29:56 +08:00
Implement delegating constructors partially. This successfully performs constructor lookup and verifies that a delegating initializer is the only initializer present. This does not perform loop detection in the initialization, but it also doesn't codegen delegating constructors at all, so this won't cause runtime infinite loops yet. llvm-svn: 126552
2011-02-27 03:13:13 +08:00
CXXCtorInitializer::CXXCtorInitializer(ASTContext &Context,
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
TypeSourceInfo *TInfo,
SourceLocation L, Expr *Init,
Implement delegating constructors partially. This successfully performs constructor lookup and verifies that a delegating initializer is the only initializer present. This does not perform loop detection in the initialization, but it also doesn't codegen delegating constructors at all, so this won't cause runtime infinite loops yet. llvm-svn: 126552
2011-02-27 03:13:13 +08:00
SourceLocation R)
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
: Initializee(TInfo), Init(Init), LParenLoc(L), RParenLoc(R),
IsDelegating(true), IsVirtual(false), IsWritten(false), SourceOrder(0) {}
Implement delegating constructors partially. This successfully performs constructor lookup and verifies that a delegating initializer is the only initializer present. This does not perform loop detection in the initialization, but it also doesn't codegen delegating constructors at all, so this won't cause runtime infinite loops yet. llvm-svn: 126552
2011-02-27 03:13:13 +08:00
Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter, more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
2011-01-09 04:30:50 +08:00
TypeLoc CXXCtorInitializer::getBaseClassLoc() const {
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
if (isBaseInitializer())
Rename CXXCtorInitializer::BaseOrMember to Initializee, since it will also be used to store the CXXConstructorDecl in a delegating constructor. llvm-svn: 123095
2011-01-09 07:01:16 +08:00
return Initializee.get<TypeSourceInfo*>()->getTypeLoc();
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
else
return TypeLoc();
}
Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter, more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
2011-01-09 04:30:50 +08:00
const Type *CXXCtorInitializer::getBaseClass() const {
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
if (isBaseInitializer())
Rename CXXCtorInitializer::BaseOrMember to Initializee, since it will also be used to store the CXXConstructorDecl in a delegating constructor. llvm-svn: 123095
2011-01-09 07:01:16 +08:00
return Initializee.get<TypeSourceInfo*>()->getType().getTypePtr();
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
else
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return nullptr;
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
}
Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter, more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
2011-01-09 04:30:50 +08:00
SourceLocation CXXCtorInitializer::getSourceLocation() const {
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
if (isInClassMemberInitializer())
return getAnyMember()->getLocation();
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
DebugInfo: Correct the debug location of non-static data member initializers This was causing some trouble for otherwise dead code removed in r225085 (reverted in r225361). The location being set for function arguments was leaking out to the call which wasn't setting its own location (so a quality bug turned into a crasher with r225085). Fix this so r225085 can be recommitted. llvm-svn: 226382
2015-01-18 08:12:58 +08:00
if (isAnyMemberInitializer())
return getMemberLocation();
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
if (TypeSourceInfo *TSInfo = Initializee.get<TypeSourceInfo*>())
return TSInfo->getTypeLoc().getLocalSourceRange().getBegin();
return SourceLocation();
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
}
Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter, more accurate, and makes it make sense for it to hold a delegating constructor call. llvm-svn: 123084
2011-01-09 04:30:50 +08:00
SourceRange CXXCtorInitializer::getSourceRange() const {
Implement support for C++11 in-class initialization of non-static data members. llvm-svn: 132878
2011-06-12 01:19:42 +08:00
if (isInClassMemberInitializer()) {
FieldDecl *D = getAnyMember();
if (Expr *I = D->getInClassInitializer())
return I->getSourceRange();
return SourceRange();
}
Improve source location information for C++ member initializers in a constructor, by keeping the DeclaratorInfo* rather than just the type and a single location. llvm-svn: 90355
2009-12-03 06:36:29 +08:00
return SourceRange(getSourceLocation(), getRParenLoc());
Initial implementation of parsing, semantic analysis, and AST-building for constructor initializations, e.g., class A { }; class B : public A { int m; public: B() : A(), m(17) { }; }; llvm-svn: 58749
2008-11-05 12:29:56 +08:00
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void CXXConstructorDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
CXXConstructorDecl *CXXConstructorDecl::CreateDeserialized(ASTContext &C,
unsigned ID,
bool Inherited) {
unsigned Extra = additionalSizeToAlloc<InheritedConstructor>(Inherited);
auto *Result = new (C, ID, Extra) CXXConstructorDecl(
C, nullptr, SourceLocation(), DeclarationNameInfo(), QualType(), nullptr,
false, false, false, false, InheritedConstructor());
Result->IsInheritingConstructor = Inherited;
return Result;
add PCH support for a bunch of C++ Decls, patch by Andrew Sutton! llvm-svn: 103301
2010-05-08 05:43:38 +08:00
}
Add support for parsing and representing C++ constructor declarations. Notes: - Constructors are never found by name lookup, so they'll never get pushed into any scope. Instead, they are stored as an OverloadedFunctionDecl in CXXRecordDecl for easy overloading. - There's a new action isCurrentClassName that determines whether an identifier is the name of the innermost class currently being defined; we use this to identify the declarator-id grammar rule that refers to a type-name. - MinimalAction does *not* support parsing constructors. - We now handle virtual and explicit function specifiers. llvm-svn: 58499
2008-10-31 17:07:45 +08:00
CXXConstructorDecl *
CXXConstructorDecl::Create(ASTContext &C, CXXRecordDecl *RD,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
SourceLocation StartLoc,
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
const DeclarationNameInfo &NameInfo,
DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated variables, but the results are imperfect. For posterity, I did: cat <<EOF > $cmdfile s/DeclaratorInfo/TypeSourceInfo/g s/DInfo/TInfo/g s/TypeTypeSourceInfo/TypeSourceInfo/g s/SourceTypeSourceInfo/TypeSourceInfo/g EOF find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \; find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \; find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \; llvm-svn: 90743
2009-12-07 10:54:59 +08:00
QualType T, TypeSourceInfo *TInfo,
Track in the AST whether a function is constexpr. llvm-svn: 137653
2011-08-16 05:04:07 +08:00
bool isExplicit, bool isInline,
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
bool isImplicitlyDeclared, bool isConstexpr,
InheritedConstructor Inherited) {
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
assert(NameInfo.getName().getNameKind()
== DeclarationName::CXXConstructorName &&
Introduction the DeclarationName class, as a single, general method of representing the names of declarations in the C family of languages. DeclarationName is used in NamedDecl to store the name of the declaration (naturally), and ObjCMethodDecl is now a NamedDecl. llvm-svn: 59441
2008-11-17 22:58:09 +08:00
"Name must refer to a constructor");
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
unsigned Extra =
additionalSizeToAlloc<InheritedConstructor>(Inherited ? 1 : 0);
return new (C, RD, Extra) CXXConstructorDecl(
C, RD, StartLoc, NameInfo, T, TInfo, isExplicit, isInline,
isImplicitlyDeclared, isConstexpr, Inherited);
Add support for parsing and representing C++ constructor declarations. Notes: - Constructors are never found by name lookup, so they'll never get pushed into any scope. Instead, they are stored as an OverloadedFunctionDecl in CXXRecordDecl for easy overloading. - There's a new action isCurrentClassName that determines whether an identifier is the name of the innermost class currently being defined; we use this to identify the declarator-id grammar rule that refers to a type-name. - MinimalAction does *not* support parsing constructors. - We now handle virtual and explicit function specifiers. llvm-svn: 58499
2008-10-31 17:07:45 +08:00
}
[modules] Deserialize CXXCtorInitializer list for a constructor lazily. Previously we'd deserialize the list of mem-initializers for a constructor when we deserialized the declaration of the constructor. That could trigger a significant amount of unnecessary work (pulling in all base classes recursively, for a start) and was causing problems for the modules buildbot due to cyclic deserializations. We now deserialize these on demand. This creates a certain amount of duplication with the handling of CXXBaseSpecifiers; I'll look into reducing that next. llvm-svn: 233052
2015-03-24 14:36:48 +08:00
CXXConstructorDecl::init_const_iterator CXXConstructorDecl::init_begin() const {
return CtorInitializers.get(getASTContext().getExternalSource());
}
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
CXXConstructorDecl *CXXConstructorDecl::getTargetConstructor() const {
assert(isDelegatingConstructor() && "Not a delegating constructor!");
Expr *E = (*init_begin())->getInit()->IgnoreImplicit();
if (CXXConstructExpr *Construct = dyn_cast<CXXConstructExpr>(E))
return Construct->getConstructor();
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return nullptr;
Rework the AST for the initializer of a delegating constructor, so that it retains source location information for the type. Aside from general goodness (being able to walk the types described in that information), we now have a proper representation for dependent delegating constructors. Fixes PR10457 (for real). llvm-svn: 143410
2011-11-01 09:16:03 +08:00
}
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
bool CXXConstructorDecl::isDefaultConstructor() const {
// C++ [class.ctor]p5:
Keep track of whether a C++ class is an aggregate. Don't allow initialization of non-aggregates with initializer lists. llvm-svn: 58757
2008-11-06 00:20:31 +08:00
// A default constructor for a class X is a constructor of class
// X that can be called without an argument.
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
return (getNumParams() == 0) ||
BuildCXXConstructExpr now returns an OwningExprResult. llvm-svn: 79975
2009-08-25 13:12:04 +08:00
(getNumParams() > 0 && getParamDecl(0)->hasDefaultArg());
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
bool
Eliminate the ASTContext argument to CXXConstructorDecl::isCopyConstructor, since the context is available in the Decl llvm-svn: 91862
2009-12-22 08:34:07 +08:00
CXXConstructorDecl::isCopyConstructor(unsigned &TypeQuals) const {
Implement the preference for move-construction over copy-construction when returning an NRVO candidate expression. For example, this properly picks the move constructor when dealing with code such as MoveOnlyType f() { MoveOnlyType mot; return mot; } The previously-XFAIL'd rvalue-references test case now works, and has been moved into the appropriate paragraph-specific test case. llvm-svn: 123992
2011-01-22 03:38:21 +08:00
return isCopyOrMoveConstructor(TypeQuals) &&
getParamDecl(0)->getType()->isLValueReferenceType();
}
bool CXXConstructorDecl::isMoveConstructor(unsigned &TypeQuals) const {
return isCopyOrMoveConstructor(TypeQuals) &&
getParamDecl(0)->getType()->isRValueReferenceType();
}
/// \brief Determine whether this is a copy or move constructor.
bool CXXConstructorDecl::isCopyOrMoveConstructor(unsigned &TypeQuals) const {
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
// C++ [class.copy]p2:
Keep track of whether a C++ class is an aggregate. Don't allow initialization of non-aggregates with initializer lists. llvm-svn: 58757
2008-11-06 00:20:31 +08:00
// A non-template constructor for class X is a copy constructor
// if its first parameter is of type X&, const X&, volatile X& or
// const volatile X&, and either there are no other parameters
// or else all other parameters have default arguments (8.3.6).
Implement the preference for move-construction over copy-construction when returning an NRVO candidate expression. For example, this properly picks the move constructor when dealing with code such as MoveOnlyType f() { MoveOnlyType mot; return mot; } The previously-XFAIL'd rvalue-references test case now works, and has been moved into the appropriate paragraph-specific test case. llvm-svn: 123992
2011-01-22 03:38:21 +08:00
// C++0x [class.copy]p3:
// A non-template constructor for class X is a move constructor if its
// first parameter is of type X&&, const X&&, volatile X&&, or
// const volatile X&&, and either there are no other parameters or else
// all other parameters have default arguments.
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
if ((getNumParams() < 1) ||
Member function templates (and instantiations/specializations thereof) are never copy constructors or copy assignment operators. llvm-svn: 84057
2009-10-14 07:45:19 +08:00
(getNumParams() > 1 && !getParamDecl(1)->hasDefaultArg()) ||
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
(getPrimaryTemplate() != nullptr) ||
(getDescribedFunctionTemplate() != nullptr))
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
return false;
Implement the preference for move-construction over copy-construction when returning an NRVO candidate expression. For example, this properly picks the move constructor when dealing with code such as MoveOnlyType f() { MoveOnlyType mot; return mot; } The previously-XFAIL'd rvalue-references test case now works, and has been moved into the appropriate paragraph-specific test case. llvm-svn: 123992
2011-01-22 03:38:21 +08:00
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
const ParmVarDecl *Param = getParamDecl(0);
Implement the preference for move-construction over copy-construction when returning an NRVO candidate expression. For example, this properly picks the move constructor when dealing with code such as MoveOnlyType f() { MoveOnlyType mot; return mot; } The previously-XFAIL'd rvalue-references test case now works, and has been moved into the appropriate paragraph-specific test case. llvm-svn: 123992
2011-01-22 03:38:21 +08:00
// Do we have a reference type?
const ReferenceType *ParamRefType = Param->getType()->getAs<ReferenceType>();
Revert r88718, which does NOT solve the constructor-template-as-copy-constructor issue. Big thanks to John for finding this llvm-svn: 88724
2009-11-14 07:59:09 +08:00
if (!ParamRefType)
return false;
Implement the preference for move-construction over copy-construction when returning an NRVO candidate expression. For example, this properly picks the move constructor when dealing with code such as MoveOnlyType f() { MoveOnlyType mot; return mot; } The previously-XFAIL'd rvalue-references test case now works, and has been moved into the appropriate paragraph-specific test case. llvm-svn: 123992
2011-01-22 03:38:21 +08:00
Revert r88718, which does NOT solve the constructor-template-as-copy-constructor issue. Big thanks to John for finding this llvm-svn: 88724
2009-11-14 07:59:09 +08:00
// Is it a reference to our class type?
Eliminate the ASTContext argument to CXXConstructorDecl::isCopyConstructor, since the context is available in the Decl llvm-svn: 91862
2009-12-22 08:34:07 +08:00
ASTContext &Context = getASTContext();
Revert r88718, which does NOT solve the constructor-template-as-copy-constructor issue. Big thanks to John for finding this llvm-svn: 88724
2009-11-14 07:59:09 +08:00
CanQualType PointeeType
= Context.getCanonicalType(ParamRefType->getPointeeType());
Make sure we're comparing the canonical types when we determine whether a constructor is a copy constructor. Sadly, I wasn't able to get down to a test case smaller than libstdc++'s <string>. llvm-svn: 81913
2009-09-16 04:50:23 +08:00
CanQualType ClassTy
= Context.getCanonicalType(Context.getTagDeclType(getParent()));
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
if (PointeeType.getUnqualifiedType() != ClassTy)
return false;
Implement the preference for move-construction over copy-construction when returning an NRVO candidate expression. For example, this properly picks the move constructor when dealing with code such as MoveOnlyType f() { MoveOnlyType mot; return mot; } The previously-XFAIL'd rvalue-references test case now works, and has been moved into the appropriate paragraph-specific test case. llvm-svn: 123992
2011-01-22 03:38:21 +08:00
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
// FIXME: other qualifiers?
Implement the preference for move-construction over copy-construction when returning an NRVO candidate expression. For example, this properly picks the move constructor when dealing with code such as MoveOnlyType f() { MoveOnlyType mot; return mot; } The previously-XFAIL'd rvalue-references test case now works, and has been moved into the appropriate paragraph-specific test case. llvm-svn: 123992
2011-01-22 03:38:21 +08:00
// We have a copy or move constructor.
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
TypeQuals = PointeeType.getCVRQualifiers();
Implement the preference for move-construction over copy-construction when returning an NRVO candidate expression. For example, this properly picks the move constructor when dealing with code such as MoveOnlyType f() { MoveOnlyType mot; return mot; } The previously-XFAIL'd rvalue-references test case now works, and has been moved into the appropriate paragraph-specific test case. llvm-svn: 123992
2011-01-22 03:38:21 +08:00
return true;
Semantic checking of constructor declarations and classification of default/copy constructors llvm-svn: 58538
2008-11-01 04:25:05 +08:00
}
Fix this for real. llvm-svn: 80377
2009-08-29 00:57:08 +08:00
bool CXXConstructorDecl::isConvertingConstructor(bool AllowExplicit) const {
Implement basic support for converting constructors in user-defined conversions. Notes: - Overload resolution for converting constructors need to prohibit user-defined conversions (hence, the test isn't -verify safe yet). - We still use hacks for conversions from a class type to itself. This will be the case until we start implicitly declaring the appropriate special member functions. (That's next on my list) llvm-svn: 58513
2008-11-01 00:23:19 +08:00
// C++ [class.conv.ctor]p1:
// A constructor declared without the function-specifier explicit
// that can be called with a single parameter specifies a
// conversion from the type of its first parameter to the type of
// its class. Such a constructor is called a converting
// constructor.
Fix this for real. llvm-svn: 80377
2009-08-29 00:57:08 +08:00
if (isExplicit() && !AllowExplicit)
Implement basic support for converting constructors in user-defined conversions. Notes: - Overload resolution for converting constructors need to prohibit user-defined conversions (hence, the test isn't -verify safe yet). - We still use hacks for conversions from a class type to itself. This will be the case until we start implicitly declaring the appropriate special member functions. (That's next on my list) llvm-svn: 58513
2008-11-01 00:23:19 +08:00
return false;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
return (getNumParams() == 0 &&
Change all the Type::getAsFoo() methods to specializations of Type::getAs(). Several of the existing methods were identical to their respective specializations, and so have been removed entirely. Several more 'leaf' optimizations were introduced. The getAsFoo() methods which imposed extra conditions, like getAsObjCInterfacePointerType(), have been left in place. llvm-svn: 82501
2009-09-22 07:43:11 +08:00
getType()->getAs<FunctionProtoType>()->isVariadic()) ||
Implement basic support for converting constructors in user-defined conversions. Notes: - Overload resolution for converting constructors need to prohibit user-defined conversions (hence, the test isn't -verify safe yet). - We still use hacks for conversions from a class type to itself. This will be the case until we start implicitly declaring the appropriate special member functions. (That's next on my list) llvm-svn: 58513
2008-11-01 00:23:19 +08:00
(getNumParams() == 1) ||
A non-explicit constructor template with a second parameter that is a parameter pack is a converting constructor. Fixes PR13003. llvm-svn: 158040
2012-06-06 07:44:51 +08:00
(getNumParams() > 1 &&
(getParamDecl(1)->hasDefaultArg() ||
getParamDecl(1)->isParameterPack()));
Implement basic support for converting constructors in user-defined conversions. Notes: - Overload resolution for converting constructors need to prohibit user-defined conversions (hence, the test isn't -verify safe yet). - We still use hacks for conversions from a class type to itself. This will be the case until we start implicitly declaring the appropriate special member functions. (That's next on my list) llvm-svn: 58513
2008-11-01 00:23:19 +08:00
}
Add support for parsing and representing C++ constructor declarations. Notes: - Constructors are never found by name lookup, so they'll never get pushed into any scope. Instead, they are stored as an OverloadedFunctionDecl in CXXRecordDecl for easy overloading. - There's a new action isCurrentClassName that determines whether an identifier is the name of the innermost class currently being defined; we use this to identify the declarator-id grammar rule that refers to a type-name. - MinimalAction does *not* support parsing constructors. - We now handle virtual and explicit function specifiers. llvm-svn: 58499
2008-10-31 17:07:45 +08:00
Improve our handling of C++ [class.copy]p3, which specifies that a constructor template will not be used to copy a class object to a value of its own type. We were eliminating all constructor templates whose specializations look like a copy constructor, which eliminated important candidates. Fixes PR8182. llvm-svn: 118418
2010-11-09 01:16:59 +08:00
bool CXXConstructorDecl::isSpecializationCopyingObject() const {
If we attempt to add a constructor template specialization that looks like a copy constructor to the overload set, just ignore it. This ensures that we don't try to use such a constructor as a copy constructor *without* triggering diagnostics at the point of declaration. Note that we *do* diagnose such copy constructors when explicitly written by the user (e.g., as an explicit specialization). llvm-svn: 88733
2009-11-14 09:20:54 +08:00
if ((getNumParams() < 1) ||
(getNumParams() > 1 && !getParamDecl(1)->hasDefaultArg()) ||
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
(getDescribedFunctionTemplate() != nullptr))
If we attempt to add a constructor template specialization that looks like a copy constructor to the overload set, just ignore it. This ensures that we don't try to use such a constructor as a copy constructor *without* triggering diagnostics at the point of declaration. Note that we *do* diagnose such copy constructors when explicitly written by the user (e.g., as an explicit specialization). llvm-svn: 88733
2009-11-14 09:20:54 +08:00
return false;
const ParmVarDecl *Param = getParamDecl(0);
ASTContext &Context = getASTContext();
CanQualType ParamType = Context.getCanonicalType(Param->getType());
// Is it the same as our our class type?
CanQualType ClassTy
= Context.getCanonicalType(Context.getTagDeclType(getParent()));
if (ParamType.getUnqualifiedType() != ClassTy)
return false;
return true;
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void CXXDestructorDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
add PCH support for a bunch of C++ Decls, patch by Andrew Sutton! llvm-svn: 103301
2010-05-08 05:43:38 +08:00
CXXDestructorDecl *
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
CXXDestructorDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
return new (C, ID)
CXXDestructorDecl(C, nullptr, SourceLocation(), DeclarationNameInfo(),
QualType(), nullptr, false, false);
add PCH support for a bunch of C++ Decls, patch by Andrew Sutton! llvm-svn: 103301
2010-05-08 05:43:38 +08:00
}
Parsing, representation, and preliminary semantic analysis of destructors. Implicit declaration of destructors (when necessary). Extended Declarator to store information about parsed constructors and destructors; this will be extended to deal with declarators that name overloaded operators (e.g., "operator +") and user-defined conversion operators (e.g., "operator int"). llvm-svn: 58767
2008-11-06 04:51:48 +08:00
CXXDestructorDecl *
CXXDestructorDecl::Create(ASTContext &C, CXXRecordDecl *RD,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
SourceLocation StartLoc,
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
const DeclarationNameInfo &NameInfo,
Pass TInfo to CXXDestructorDecl::Create(), just like we do for other function decls. Reviewed by rjmccall and nlewycky. llvm-svn: 116979
2010-10-21 08:44:50 +08:00
QualType T, TypeSourceInfo *TInfo,
Track in the AST whether a function is constexpr. llvm-svn: 137653
2011-08-16 05:04:07 +08:00
bool isInline, bool isImplicitlyDeclared) {
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
assert(NameInfo.getName().getNameKind()
== DeclarationName::CXXDestructorName &&
Introduction the DeclarationName class, as a single, general method of representing the names of declarations in the C family of languages. DeclarationName is used in NamedDecl to store the name of the declaration (naturally), and ObjCMethodDecl is now a NamedDecl. llvm-svn: 59441
2008-11-17 22:58:09 +08:00
"Name must refer to a destructor");
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
return new (C, RD) CXXDestructorDecl(C, RD, StartLoc, NameInfo, T, TInfo,
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
isInline, isImplicitlyDeclared);
Parsing, representation, and preliminary semantic analysis of destructors. Implicit declaration of destructors (when necessary). Extended Declarator to store information about parsed constructors and destructors; this will be extended to deal with declarators that name overloaded operators (e.g., "operator +") and user-defined conversion operators (e.g., "operator int"). llvm-svn: 58767
2008-11-06 04:51:48 +08:00
}
Support for destroying operator delete, per C++2a proposal P0722. This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
2017-10-13 09:55:36 +08:00
void CXXDestructorDecl::setOperatorDelete(FunctionDecl *OD, Expr *ThisArg) {
[modules] Don't clobber a destructor's operator delete when adding another one; move the operator delete updating into a separate update record so we can cope with updating another module's destructor's operator delete. llvm-svn: 231735
2015-03-10 09:41:22 +08:00
auto *First = cast<CXXDestructorDecl>(getFirstDecl());
if (OD && !First->OperatorDelete) {
First->OperatorDelete = OD;
Support for destroying operator delete, per C++2a proposal P0722. This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
2017-10-13 09:55:36 +08:00
First->OperatorDeleteThisArg = ThisArg;
[modules] Don't clobber a destructor's operator delete when adding another one; move the operator delete updating into a separate update record so we can cope with updating another module's destructor's operator delete. llvm-svn: 231735
2015-03-10 09:41:22 +08:00
if (auto *L = getASTMutationListener())
Support for destroying operator delete, per C++2a proposal P0722. This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
2017-10-13 09:55:36 +08:00
L->ResolvedOperatorDelete(First, OD, ThisArg);
[modules] Don't clobber a destructor's operator delete when adding another one; move the operator delete updating into a separate update record so we can cope with updating another module's destructor's operator delete. llvm-svn: 231735
2015-03-10 09:41:22 +08:00
}
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void CXXConversionDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
add PCH support for a bunch of C++ Decls, patch by Andrew Sutton! llvm-svn: 103301
2010-05-08 05:43:38 +08:00
CXXConversionDecl *
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
CXXConversionDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
return new (C, ID) CXXConversionDecl(C, nullptr, SourceLocation(),
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
DeclarationNameInfo(), QualType(),
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
nullptr, false, false, false,
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
SourceLocation());
add PCH support for a bunch of C++ Decls, patch by Andrew Sutton! llvm-svn: 103301
2010-05-08 05:43:38 +08:00
}
Parsing, ASTs, and semantic analysis for the declaration of conversion functions in C++, e.g., struct X { operator bool() const; }; Note that these conversions don't actually do anything, since we don't yet have the ability to use them for implicit or explicit conversions. llvm-svn: 58860
2008-11-08 04:08:42 +08:00
CXXConversionDecl *
CXXConversionDecl::Create(ASTContext &C, CXXRecordDecl *RD,
Fixed source range for all DeclaratorDecl's. llvm-svn: 127225
2011-03-08 16:55:46 +08:00
SourceLocation StartLoc,
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
const DeclarationNameInfo &NameInfo,
DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated variables, but the results are imperfect. For posterity, I did: cat <<EOF > $cmdfile s/DeclaratorInfo/TypeSourceInfo/g s/DInfo/TInfo/g s/TypeTypeSourceInfo/TypeSourceInfo/g s/SourceTypeSourceInfo/TypeSourceInfo/g EOF find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \; find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \; find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \; llvm-svn: 90743
2009-12-07 10:54:59 +08:00
QualType T, TypeSourceInfo *TInfo,
Teach libclang's token-annotation logic about context-sensitive keywords for Objective-C+ and C++0x. llvm-svn: 127253
2011-03-09 01:10:18 +08:00
bool isInline, bool isExplicit,
Track in the AST whether a function is constexpr. llvm-svn: 137653
2011-08-16 05:04:07 +08:00
bool isConstexpr, SourceLocation EndLocation) {
Added locations and type source info for DeclarationName. llvm-svn: 110860
2010-08-12 06:01:17 +08:00
assert(NameInfo.getName().getNameKind()
== DeclarationName::CXXConversionFunctionName &&
Introduction the DeclarationName class, as a single, general method of representing the names of declarations in the C family of languages. DeclarationName is used in NamedDecl to store the name of the declaration (naturally), and ObjCMethodDecl is now a NamedDecl. llvm-svn: 59441
2008-11-17 22:58:09 +08:00
"Name must refer to a conversion function");
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
return new (C, RD) CXXConversionDecl(C, RD, StartLoc, NameInfo, T, TInfo,
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
isInline, isExplicit, isConstexpr,
EndLocation);
Parsing, ASTs, and semantic analysis for the declaration of conversion functions in C++, e.g., struct X { operator bool() const; }; Note that these conversions don't actually do anything, since we don't yet have the ability to use them for implicit or explicit conversions. llvm-svn: 58860
2008-11-08 04:08:42 +08:00
}
Implicitly define a lambda's conversion functions (to function pointers and block pointers). We use dummy definitions to keep the invariant that an implicit, used definition has a body; IR generation will substitute the actual contents, since they can't be represented as C++. For the block pointer case, compute the copy-initialization needed to capture the lambda object in the block, which IR generation will need later. llvm-svn: 150645
2012-02-16 09:06:16 +08:00
bool CXXConversionDecl::isLambdaToBlockPointerConversion() const {
return isImplicit() && getParent()->isLambda() &&
getConversionType()->isBlockPointerType();
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void LinkageSpecDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
LinkageSpecDecl is c++ specific, move it to DeclCXX llvm-svn: 58704
2008-11-05 00:51:42 +08:00
LinkageSpecDecl *LinkageSpecDecl::Create(ASTContext &C,
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
DeclContext *DC,
Fixed source range for StaticAssertDecl and LinkageSpecDecl. Fixed source range for declarations using postfix types. llvm-svn: 127251
2011-03-09 00:41:52 +08:00
SourceLocation ExternLoc,
SourceLocation LangLoc,
Fixed end source location for LinkageSpecDecl. llvm-svn: 126943
2011-03-03 22:52:38 +08:00
LanguageIDs Lang,
Add r180263 back, but fix hasBraces() to be correct during parsing. Original commit message: Fix a case in linkage computation that should check for single line extern "C". llvm-svn: 180591
2013-04-26 09:30:23 +08:00
bool HasBraces) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
return new (C, DC) LinkageSpecDecl(DC, ExternLoc, LangLoc, Lang, HasBraces);
Make linkage-specifications hold on to all of their declarations llvm-svn: 61110
2008-12-17 06:23:02 +08:00
}
Semantic analysis, ASTs, and unqualified name lookup support for C++ using directives, from Piotr Rak! llvm-svn: 63646
2009-02-04 03:21:40 +08:00
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
LinkageSpecDecl *LinkageSpecDecl::CreateDeserialized(ASTContext &C,
unsigned ID) {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return new (C, ID) LinkageSpecDecl(nullptr, SourceLocation(),
SourceLocation(), lang_c, false);
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void UsingDirectiveDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
Semantic analysis, ASTs, and unqualified name lookup support for C++ using directives, from Piotr Rak! llvm-svn: 63646
2009-02-04 03:21:40 +08:00
UsingDirectiveDecl *UsingDirectiveDecl::Create(ASTContext &C, DeclContext *DC,
SourceLocation L,
SourceLocation NamespaceLoc,
Push nested-name-specifier source location information into using directives. llvm-svn: 126489
2011-02-26 00:33:46 +08:00
NestedNameSpecifierLoc QualifierLoc,
Semantic analysis, ASTs, and unqualified name lookup support for C++ using directives, from Piotr Rak! llvm-svn: 63646
2009-02-04 03:21:40 +08:00
SourceLocation IdentLoc,
Let using directives refer to namespace aliases. Fixes PR5479. llvm-svn: 89657
2009-11-23 23:34:23 +08:00
NamedDecl *Used,
Semantic analysis, ASTs, and unqualified name lookup support for C++ using directives, from Piotr Rak! llvm-svn: 63646
2009-02-04 03:21:40 +08:00
DeclContext *CommonAncestor) {
Let using directives refer to namespace aliases. Fixes PR5479. llvm-svn: 89657
2009-11-23 23:34:23 +08:00
if (NamespaceDecl *NS = dyn_cast_or_null<NamespaceDecl>(Used))
Used = NS->getOriginalNamespace();
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
return new (C, DC) UsingDirectiveDecl(DC, L, NamespaceLoc, QualifierLoc,
IdentLoc, Used, CommonAncestor);
Semantic analysis, ASTs, and unqualified name lookup support for C++ using directives, from Piotr Rak! llvm-svn: 63646
2009-02-04 03:21:40 +08:00
}
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
UsingDirectiveDecl *UsingDirectiveDecl::CreateDeserialized(ASTContext &C,
unsigned ID) {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return new (C, ID) UsingDirectiveDecl(nullptr, SourceLocation(),
SourceLocation(),
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
NestedNameSpecifierLoc(),
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
SourceLocation(), nullptr, nullptr);
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
Let using directives refer to namespace aliases. Fixes PR5479. llvm-svn: 89657
2009-11-23 23:34:23 +08:00
NamespaceDecl *UsingDirectiveDecl::getNominatedNamespace() {
if (NamespaceAliasDecl *NA =
dyn_cast_or_null<NamespaceAliasDecl>(NominatedNamespace))
return NA->getNamespace();
return cast_or_null<NamespaceDecl>(NominatedNamespace);
}
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
NamespaceDecl::NamespaceDecl(ASTContext &C, DeclContext *DC, bool Inline,
SourceLocation StartLoc, SourceLocation IdLoc,
IdentifierInfo *Id, NamespaceDecl *PrevDecl)
: NamedDecl(Namespace, DC, IdLoc, Id), DeclContext(Namespace),
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
redeclarable_base(C), LocStart(StartLoc),
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
AnonOrFirstNamespaceAndInline(nullptr, Inline) {
Rename some functions for consistency. Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
2013-10-17 23:37:26 +08:00
setPreviousDecl(PrevDecl);
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
Switch NamespaceDecl from its own hand-rolled redeclaration chain over to Redeclarable<NamespaceDecl>, so that we benefit from the improveed redeclaration deserialization and merging logic provided by Redeclarable<T>. Otherwise, no functionality change. As a drive-by fix, collapse the "inline" bit into the low bit of the original namespace/anonymous namespace, saving 8 bytes per NamespaceDecl on x86_64. llvm-svn: 147729
2012-01-07 17:11:48 +08:00
if (PrevDecl)
AnonOrFirstNamespaceAndInline.setPointer(PrevDecl->getOriginalNamespace());
}
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
NamespaceDecl *NamespaceDecl::Create(ASTContext &C, DeclContext *DC,
Switch NamespaceDecl from its own hand-rolled redeclaration chain over to Redeclarable<NamespaceDecl>, so that we benefit from the improveed redeclaration deserialization and merging logic provided by Redeclarable<T>. Otherwise, no functionality change. As a drive-by fix, collapse the "inline" bit into the low bit of the original namespace/anonymous namespace, saving 8 bytes per NamespaceDecl on x86_64. llvm-svn: 147729
2012-01-07 17:11:48 +08:00
bool Inline, SourceLocation StartLoc,
SourceLocation IdLoc, IdentifierInfo *Id,
NamespaceDecl *PrevDecl) {
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
return new (C, DC) NamespaceDecl(C, DC, Inline, StartLoc, IdLoc, Id,
PrevDecl);
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
NamespaceDecl *NamespaceDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
If a declaration is loaded, and then a module import adds a redeclaration, then ensure that querying the first declaration for its most recent declaration checks for redeclarations from the imported module. This works as follows: * The 'most recent' pointer on a canonical declaration grows a pointer to the external AST source and a generation number (space- and time-optimized for the case where there is no external source). * Each time the 'most recent' pointer is queried, if it has an external source, we check whether it's up to date, and update it if not. * The ancillary data stored on the canonical declaration is allocated lazily to avoid filling it in for declarations that end up being non-canonical. We'll still perform a redundant (ASTContext) allocation if someone asks for the most recent declaration from a decl before setPreviousDecl is called, but such cases are probably all bugs, and are now easy to find. Some finessing is still in order here -- in particular, we use a very general mechanism for handling the DefinitionData pointer on CXXRecordData, and a more targeted approach would be more compact. Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was addressing only a corner of the full problem space here. That's not covered by this patch. Early performance benchmarks show that this makes no measurable difference to Clang performance without modules enabled (and fixes a major correctness issue with modules enabled). I'll revert if a full performance comparison shows any problems. llvm-svn: 209046
2014-05-17 07:01:30 +08:00
return new (C, ID) NamespaceDecl(C, nullptr, false, SourceLocation(),
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
SourceLocation(), nullptr, nullptr);
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
[ptr-traits] Move methods manipulating PointerUnions, DenseMap pointer keys, and PointerIntPairs where the pointee types are incomplete out-of-line to where we have the complete type. This is the standard pattern used throughout the AST library to address the inherently mutually cross referenced nature of the AST. This is part of a series of patches to allow LLVM to check for complete pointee types when computing its pointer traits. This is absolutely necessary to get correct (or reproducible) results for things like how many low bits are guaranteed to be zero. llvm-svn: 256612
2015-12-30 11:24:14 +08:00
NamespaceDecl *NamespaceDecl::getOriginalNamespace() {
if (isFirstDecl())
return this;
return AnonOrFirstNamespaceAndInline.getPointer();
}
const NamespaceDecl *NamespaceDecl::getOriginalNamespace() const {
if (isFirstDecl())
return this;
return AnonOrFirstNamespaceAndInline.getPointer();
}
bool NamespaceDecl::isOriginalNamespace() const { return isFirstDecl(); }
Stop all the Decl classes poking at Redeclarable's data member directly, and make getNextRedeclaration follow the pattern of its friends getPreviousDecl and getMostRecentDecl. llvm-svn: 208467
2014-05-10 09:17:36 +08:00
NamespaceDecl *NamespaceDecl::getNextRedeclarationImpl() {
return getNextRedeclaration();
Move these virtual methods out of line. llvm-svn: 195767
2013-11-26 23:12:20 +08:00
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
Move these virtual methods out of line. llvm-svn: 195767
2013-11-26 23:12:20 +08:00
NamespaceDecl *NamespaceDecl::getPreviousDeclImpl() {
return getPreviousDecl();
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
Move these virtual methods out of line. llvm-svn: 195767
2013-11-26 23:12:20 +08:00
NamespaceDecl *NamespaceDecl::getMostRecentDeclImpl() {
return getMostRecentDecl();
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void NamespaceAliasDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
[modules] Make NamespaceAliasDecl redeclarable, as it should be. This fixes merging of namespace aliases across modules and improves source fidelity. Incidentally also fixes PR20816. llvm-svn: 217103
2014-09-04 07:11:22 +08:00
NamespaceAliasDecl *NamespaceAliasDecl::getNextRedeclarationImpl() {
return getNextRedeclaration();
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
[modules] Make NamespaceAliasDecl redeclarable, as it should be. This fixes merging of namespace aliases across modules and improves source fidelity. Incidentally also fixes PR20816. llvm-svn: 217103
2014-09-04 07:11:22 +08:00
NamespaceAliasDecl *NamespaceAliasDecl::getPreviousDeclImpl() {
return getPreviousDecl();
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
[modules] Make NamespaceAliasDecl redeclarable, as it should be. This fixes merging of namespace aliases across modules and improves source fidelity. Incidentally also fixes PR20816. llvm-svn: 217103
2014-09-04 07:11:22 +08:00
NamespaceAliasDecl *NamespaceAliasDecl::getMostRecentDeclImpl() {
return getMostRecentDecl();
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
NamespaceAliasDecl *NamespaceAliasDecl::Create(ASTContext &C, DeclContext *DC,
Implement libclang support for using directives (cursor + visitation + suppressing USRs). Also, fix up the source location information for using directives so that the declaration location refers to the namespace name. llvm-svn: 112693
2010-09-01 11:07:18 +08:00
SourceLocation UsingLoc,
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
SourceLocation AliasLoc,
IdentifierInfo *Alias,
Push nested-name-specifier source location information into namespace aliases. llvm-svn: 126496
2011-02-26 01:08:07 +08:00
NestedNameSpecifierLoc QualifierLoc,
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
SourceLocation IdentLoc,
Create AST nodes for namespace aliases. llvm-svn: 67962
2009-03-29 06:58:02 +08:00
NamedDecl *Namespace) {
[modules] Make NamespaceAliasDecl redeclarable, as it should be. This fixes merging of namespace aliases across modules and improves source fidelity. Incidentally also fixes PR20816. llvm-svn: 217103
2014-09-04 07:11:22 +08:00
// FIXME: Preserve the aliased namespace as written.
Let using directives refer to namespace aliases. Fixes PR5479. llvm-svn: 89657
2009-11-23 23:34:23 +08:00
if (NamespaceDecl *NS = dyn_cast_or_null<NamespaceDecl>(Namespace))
Namespace = NS->getOriginalNamespace();
[modules] Make NamespaceAliasDecl redeclarable, as it should be. This fixes merging of namespace aliases across modules and improves source fidelity. Incidentally also fixes PR20816. llvm-svn: 217103
2014-09-04 07:11:22 +08:00
return new (C, DC) NamespaceAliasDecl(C, DC, UsingLoc, AliasLoc, Alias,
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
QualifierLoc, IdentLoc, Namespace);
Create AST nodes for namespace aliases. llvm-svn: 67962
2009-03-29 06:58:02 +08:00
}
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
NamespaceAliasDecl *
NamespaceAliasDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
[modules] Make NamespaceAliasDecl redeclarable, as it should be. This fixes merging of namespace aliases across modules and improves source fidelity. Incidentally also fixes PR20816. llvm-svn: 217103
2014-09-04 07:11:22 +08:00
return new (C, ID) NamespaceAliasDecl(C, nullptr, SourceLocation(),
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
SourceLocation(), nullptr,
NestedNameSpecifierLoc(),
SourceLocation(), nullptr);
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void UsingShadowDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
UsingShadowDecl::UsingShadowDecl(Kind K, ASTContext &C, DeclContext *DC,
SourceLocation Loc, UsingDecl *Using,
NamedDecl *Target)
: NamedDecl(K, DC, Loc, Using ? Using->getDeclName() : DeclarationName()),
Serialize the IDNS for a UsingShadowDecl rather than recomputing it. Attempting to recompute it are doomed to fail because the IDNS of a declaration is not necessarily preserved across serialization and deserialization (in turn because whether a friend declaration is visible depends on whether some prior non-friend declaration exists). llvm-svn: 321921
2018-01-06 09:07:05 +08:00
redeclarable_base(C), Underlying(),
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
UsingOrNextShadow(cast<NamedDecl>(Using)) {
if (Target)
Serialize the IDNS for a UsingShadowDecl rather than recomputing it. Attempting to recompute it are doomed to fail because the IDNS of a declaration is not necessarily preserved across serialization and deserialization (in turn because whether a friend declaration is visible depends on whether some prior non-friend declaration exists). llvm-svn: 321921
2018-01-06 09:07:05 +08:00
setTargetDecl(Target);
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
setImplicit();
}
UsingShadowDecl::UsingShadowDecl(Kind K, ASTContext &C, EmptyShell Empty)
: NamedDecl(K, nullptr, SourceLocation(), DeclarationName()),
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
redeclarable_base(C) {}
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
UsingShadowDecl *
UsingShadowDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
return new (C, ID) UsingShadowDecl(UsingShadow, C, EmptyShell());
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
Replace UsingDecl's SmallPtrSet of UsingShadowDecls with a linked list to avoid leaking memory. Fixes rdar://8649963. llvm-svn: 118674
2010-11-10 13:40:41 +08:00
UsingDecl *UsingShadowDecl::getUsingDecl() const {
const UsingShadowDecl *Shadow = this;
while (const UsingShadowDecl *NextShadow =
dyn_cast<UsingShadowDecl>(Shadow->UsingOrNextShadow))
Shadow = NextShadow;
return cast<UsingDecl>(Shadow->UsingOrNextShadow);
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void ConstructorUsingShadowDecl::anchor() {}
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: 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
2016-06-29 03:03:57 +08:00
ConstructorUsingShadowDecl *
ConstructorUsingShadowDecl::Create(ASTContext &C, DeclContext *DC,
SourceLocation Loc, UsingDecl *Using,
NamedDecl *Target, bool IsVirtual) {
return new (C, DC) ConstructorUsingShadowDecl(C, DC, Loc, Using, Target,
IsVirtual);
}
ConstructorUsingShadowDecl *
ConstructorUsingShadowDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
return new (C, ID) ConstructorUsingShadowDecl(C, EmptyShell());
}
CXXRecordDecl *ConstructorUsingShadowDecl::getNominatedBaseClass() const {
return getUsingDecl()->getQualifier()->getAsRecordDecl();
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void UsingDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
Replace UsingDecl's SmallPtrSet of UsingShadowDecls with a linked list to avoid leaking memory. Fixes rdar://8649963. llvm-svn: 118674
2010-11-10 13:40:41 +08:00
void UsingDecl::addShadowDecl(UsingShadowDecl *S) {
assert(std::find(shadow_begin(), shadow_end(), S) == shadow_end() &&
"declaration already in set");
assert(S->getUsingDecl() == this);
Pack UsingDecl more. 88 -> 80 bytes on x86_64. llvm-svn: 147736
2012-01-08 03:09:05 +08:00
if (FirstUsingShadow.getPointer())
S->UsingOrNextShadow = FirstUsingShadow.getPointer();
FirstUsingShadow.setPointer(S);
Replace UsingDecl's SmallPtrSet of UsingShadowDecls with a linked list to avoid leaking memory. Fixes rdar://8649963. llvm-svn: 118674
2010-11-10 13:40:41 +08:00
}
void UsingDecl::removeShadowDecl(UsingShadowDecl *S) {
assert(std::find(shadow_begin(), shadow_end(), S) != shadow_end() &&
"declaration not in set");
assert(S->getUsingDecl() == this);
// Remove S from the shadow decl chain. This is O(n) but hopefully rare.
Pack UsingDecl more. 88 -> 80 bytes on x86_64. llvm-svn: 147736
2012-01-08 03:09:05 +08:00
if (FirstUsingShadow.getPointer() == S) {
FirstUsingShadow.setPointer(
dyn_cast<UsingShadowDecl>(S->UsingOrNextShadow));
Replace UsingDecl's SmallPtrSet of UsingShadowDecls with a linked list to avoid leaking memory. Fixes rdar://8649963. llvm-svn: 118674
2010-11-10 13:40:41 +08:00
S->UsingOrNextShadow = this;
return;
}
Pack UsingDecl more. 88 -> 80 bytes on x86_64. llvm-svn: 147736
2012-01-08 03:09:05 +08:00
UsingShadowDecl *Prev = FirstUsingShadow.getPointer();
Replace UsingDecl's SmallPtrSet of UsingShadowDecls with a linked list to avoid leaking memory. Fixes rdar://8649963. llvm-svn: 118674
2010-11-10 13:40:41 +08:00
while (Prev->UsingOrNextShadow != S)
Prev = cast<UsingShadowDecl>(Prev->UsingOrNextShadow);
Prev->UsingOrNextShadow = S->UsingOrNextShadow;
S->UsingOrNextShadow = this;
}
Update UsingDecl, UnresolvedUsingTypenameDecl, and UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the extremely-lossy NestedNameSpecifier/SourceRange pair it used to use, improving source-location information. Various infrastructure updates to support NestedNameSpecifierLoc: - AST/PCH (de-)serialization - Recursive AST visitor - libclang traversal (including the first tests of this functionality) llvm-svn: 126459
2011-02-25 08:36:19 +08:00
UsingDecl *UsingDecl::Create(ASTContext &C, DeclContext *DC, SourceLocation UL,
NestedNameSpecifierLoc QualifierLoc,
Added locations and type source info for DeclarationName inside UsingDecl. llvm-svn: 110912
2010-08-12 19:46:03 +08:00
const DeclarationNameInfo &NameInfo,
Improve clarity/consistency of a few UsingDecl methods and related helpers. No functionality change. In Sema helper functions: * renamed isTypeName as HasTypenameKeyword In UsingDecl: * renamed get/setUsingLocation to get/setUsingLoc * renamed is/setTypeName as has/setTypename llvm-svn: 186816
2013-07-22 18:54:09 +08:00
bool HasTypename) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
return new (C, DC) UsingDecl(DC, UL, QualifierLoc, NameInfo, HasTypename);
Parsing and AST support for using declarations, from John Thompson! llvm-svn: 73812
2009-06-20 08:51:54 +08:00
}
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
UsingDecl *UsingDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return new (C, ID) UsingDecl(nullptr, SourceLocation(),
NestedNameSpecifierLoc(), DeclarationNameInfo(),
false);
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
Fixed source range of C++03 access declarations. llvm-svn: 186522
2013-07-18 01:28:56 +08:00
SourceRange UsingDecl::getSourceRange() const {
SourceLocation Begin = isAccessDeclaration()
? getQualifierLoc().getBeginLoc() : UsingLocation;
return SourceRange(Begin, getNameInfo().getEndLoc());
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void UsingPackDecl::anchor() {}
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
UsingPackDecl *UsingPackDecl::Create(ASTContext &C, DeclContext *DC,
NamedDecl *InstantiatedFrom,
ArrayRef<NamedDecl *> UsingDecls) {
size_t Extra = additionalSizeToAlloc<NamedDecl *>(UsingDecls.size());
return new (C, DC, Extra) UsingPackDecl(DC, InstantiatedFrom, UsingDecls);
}
UsingPackDecl *UsingPackDecl::CreateDeserialized(ASTContext &C, unsigned ID,
unsigned NumExpansions) {
size_t Extra = additionalSizeToAlloc<NamedDecl *>(NumExpansions);
auto *Result = new (C, ID, Extra) UsingPackDecl(nullptr, nullptr, None);
Result->NumExpansions = NumExpansions;
auto *Trail = Result->getTrailingObjects<NamedDecl *>();
for (unsigned I = 0; I != NumExpansions; ++I)
new (Trail + I) NamedDecl*(nullptr);
return Result;
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void UnresolvedUsingValueDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
Incremental progress on using declarations. Split UnresolvedUsingDecl into two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
2009-11-18 10:36:19 +08:00
UnresolvedUsingValueDecl *
UnresolvedUsingValueDecl::Create(ASTContext &C, DeclContext *DC,
SourceLocation UsingLoc,
Update UsingDecl, UnresolvedUsingTypenameDecl, and UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the extremely-lossy NestedNameSpecifier/SourceRange pair it used to use, improving source-location information. Various infrastructure updates to support NestedNameSpecifierLoc: - AST/PCH (de-)serialization - Recursive AST visitor - libclang traversal (including the first tests of this functionality) llvm-svn: 126459
2011-02-25 08:36:19 +08:00
NestedNameSpecifierLoc QualifierLoc,
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
const DeclarationNameInfo &NameInfo,
SourceLocation EllipsisLoc) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
return new (C, DC) UnresolvedUsingValueDecl(DC, C.DependentTy, UsingLoc,
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
QualifierLoc, NameInfo,
EllipsisLoc);
Incremental progress on using declarations. Split UnresolvedUsingDecl into two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
2009-11-18 10:36:19 +08:00
}
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
UnresolvedUsingValueDecl *
UnresolvedUsingValueDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return new (C, ID) UnresolvedUsingValueDecl(nullptr, QualType(),
SourceLocation(),
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
NestedNameSpecifierLoc(),
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
DeclarationNameInfo(),
SourceLocation());
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
Fixed source range of C++03 access declarations. llvm-svn: 186522
2013-07-18 01:28:56 +08:00
SourceRange UnresolvedUsingValueDecl::getSourceRange() const {
SourceLocation Begin = isAccessDeclaration()
? getQualifierLoc().getBeginLoc() : UsingLocation;
return SourceRange(Begin, getNameInfo().getEndLoc());
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void UnresolvedUsingTypenameDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
Incremental progress on using declarations. Split UnresolvedUsingDecl into two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
2009-11-18 10:36:19 +08:00
UnresolvedUsingTypenameDecl *
UnresolvedUsingTypenameDecl::Create(ASTContext &C, DeclContext *DC,
SourceLocation UsingLoc,
SourceLocation TypenameLoc,
Update UsingDecl, UnresolvedUsingTypenameDecl, and UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the extremely-lossy NestedNameSpecifier/SourceRange pair it used to use, improving source-location information. Various infrastructure updates to support NestedNameSpecifierLoc: - AST/PCH (de-)serialization - Recursive AST visitor - libclang traversal (including the first tests of this functionality) llvm-svn: 126459
2011-02-25 08:36:19 +08:00
NestedNameSpecifierLoc QualifierLoc,
Incremental progress on using declarations. Split UnresolvedUsingDecl into two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
2009-11-18 10:36:19 +08:00
SourceLocation TargetNameLoc,
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
DeclarationName TargetName,
SourceLocation EllipsisLoc) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
return new (C, DC) UnresolvedUsingTypenameDecl(
DC, UsingLoc, TypenameLoc, QualifierLoc, TargetNameLoc,
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
TargetName.getAsIdentifierInfo(), EllipsisLoc);
Check in UnresolvedUsingDecl. llvm-svn: 80336
2009-08-28 13:30:28 +08:00
}
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
UnresolvedUsingTypenameDecl *
UnresolvedUsingTypenameDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
return new (C, ID) UnresolvedUsingTypenameDecl(
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
nullptr, SourceLocation(), SourceLocation(), NestedNameSpecifierLoc(),
[c++1z] P0195R2: Support pack-expansion of using-declarations. This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
2016-12-21 05:35:28 +08:00
SourceLocation(), nullptr, SourceLocation());
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
[AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 318216
2017-11-15 07:13:32 +08:00
void StaticAssertDecl::anchor() {}
Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146959
2011-12-20 10:48:34 +08:00
More static_assert work. Check that the assert expr is valid and show an error if it's false. Create the declaration and add it to the current context. llvm-svn: 66995
2009-03-14 08:25:26 +08:00
StaticAssertDecl *StaticAssertDecl::Create(ASTContext &C, DeclContext *DC,
Fixed source range for StaticAssertDecl and LinkageSpecDecl. Fixed source range for declarations using postfix types. llvm-svn: 127251
2011-03-09 00:41:52 +08:00
SourceLocation StaticAssertLoc,
Expr *AssertExpr,
StringLiteral *Message,
Stop instantiating a class if we hit a static_assert failure. Also, if the static_assert fails when parsing the template, don't diagnose it again on every instantiation. llvm-svn: 160088
2012-07-12 06:37:56 +08:00
SourceLocation RParenLoc,
bool Failed) {
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
return new (C, DC) StaticAssertDecl(DC, StaticAssertLoc, AssertExpr, Message,
RParenLoc, Failed);
More static_assert work. Check that the assert expr is valid and show an error if it's false. Create the declaration and add it to the current context. llvm-svn: 66995
2009-03-14 08:25:26 +08:00
}
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
StaticAssertDecl *StaticAssertDecl::CreateDeserialized(ASTContext &C,
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
unsigned ID) {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return new (C, ID) StaticAssertDecl(nullptr, SourceLocation(), nullptr,
nullptr, SourceLocation(), false);
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
}
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
void BindingDecl::anchor() {}
BindingDecl *BindingDecl::Create(ASTContext &C, DeclContext *DC,
SourceLocation IdLoc, IdentifierInfo *Id) {
Remove unused and undesirable reference from BindingDecl to DecompositionDecl. llvm-svn: 278448
2016-08-12 08:53:41 +08:00
return new (C, DC) BindingDecl(DC, IdLoc, Id);
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
}
BindingDecl *BindingDecl::CreateDeserialized(ASTContext &C, unsigned ID) {
Remove unused and undesirable reference from BindingDecl to DecompositionDecl. llvm-svn: 278448
2016-08-12 08:53:41 +08:00
return new (C, ID) BindingDecl(nullptr, SourceLocation(), nullptr);
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
}
Explicitly generate a reference variable to hold the initializer for a tuple-like decomposition declaration. This significantly simplifies the semantics of BindingDecls for AST consumers (they can now always be evalated at the point of use). llvm-svn: 278640
2016-08-15 07:15:52 +08:00
VarDecl *BindingDecl::getHoldingVar() const {
Expr *B = getBinding();
if (!B)
return nullptr;
auto *DRE = dyn_cast<DeclRefExpr>(B->IgnoreImplicit());
if (!DRE)
return nullptr;
auto *VD = dyn_cast<VarDecl>(DRE->getDecl());
assert(VD->isImplicit() && "holding var for binding decl not implicit");
return VD;
}
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
void DecompositionDecl::anchor() {}
DecompositionDecl *DecompositionDecl::Create(ASTContext &C, DeclContext *DC,
SourceLocation StartLoc,
SourceLocation LSquareLoc,
QualType T, TypeSourceInfo *TInfo,
StorageClass SC,
ArrayRef<BindingDecl *> Bindings) {
size_t Extra = additionalSizeToAlloc<BindingDecl *>(Bindings.size());
return new (C, DC, Extra)
DecompositionDecl(C, DC, StartLoc, LSquareLoc, T, TInfo, SC, Bindings);
}
DecompositionDecl *DecompositionDecl::CreateDeserialized(ASTContext &C,
unsigned ID,
unsigned NumBindings) {
size_t Extra = additionalSizeToAlloc<BindingDecl *>(NumBindings);
P0217R3: serialization/deserialization support for c++17 decomposition declarations. llvm-svn: 278460
2016-08-12 10:21:25 +08:00
auto *Result = new (C, ID, Extra)
DecompositionDecl(C, nullptr, SourceLocation(), SourceLocation(),
QualType(), nullptr, StorageClass(), None);
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +08:00
// Set up and clean out the bindings array.
Result->NumBindings = NumBindings;
auto *Trail = Result->getTrailingObjects<BindingDecl *>();
for (unsigned I = 0; I != NumBindings; ++I)
new (Trail + I) BindingDecl*(nullptr);
return Result;
}
P0217R3: Perform semantic checks and initialization for the bindings in a decomposition declaration for arrays, aggregate-like structs, tuple-like types, and (as an extension) for complex and vector types. llvm-svn: 278435
2016-08-12 06:25:46 +08:00
void DecompositionDecl::printName(llvm::raw_ostream &os) const {
os << '[';
bool Comma = false;
for (auto *B : bindings()) {
if (Comma)
os << ", ";
B->printName(os);
Comma = true;
}
os << ']';
}
Add class-specific operator new to Decl hierarchy. This guarantees that Decls can't accidentally be allocated the wrong way (missing prefix data for decls from AST files, for instance) and simplifies the CreateDeserialized functions a little. An extra DeclContext* parameter to the not-from-AST-file operator new allows us to ensure that we don't accidentally call the wrong one when deserializing (when we don't have a DeclContext), allows some extra checks, and prepares for some planned modules-related changes to Decl allocation. No functionality change intended. llvm-svn: 195426
2013-11-22 17:01:48 +08:00
MSPropertyDecl *MSPropertyDecl::Create(ASTContext &C, DeclContext *DC,
SourceLocation L, DeclarationName N,
QualType T, TypeSourceInfo *TInfo,
SourceLocation StartL,
IdentifierInfo *Getter,
IdentifierInfo *Setter) {
return new (C, DC) MSPropertyDecl(DC, L, N, T, TInfo, StartL, Getter, Setter);
}
MSPropertyDecl *MSPropertyDecl::CreateDeserialized(ASTContext &C,
unsigned ID) {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return new (C, ID) MSPropertyDecl(nullptr, SourceLocation(),
DeclarationName(), QualType(), nullptr,
SourceLocation(), nullptr, nullptr);
When creating declarations that are deserialized from an module file, go through a central allocation routine Decl::AllocateDeserializedDecl(). No actual functionality change (yet). llvm-svn: 147614
2012-01-06 05:55:30 +08:00
}
Add const DiagnosticBuilder &operator<<(const DiagnosticBuilder &DB, AccessSpecifier AS); so we can easily add access specifiers to diagnostics. llvm-svn: 67795
2009-03-27 07:46:50 +08:00
static const char *getAccessName(AccessSpecifier AS) {
switch (AS) {
case AS_none:
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Invalid access specifier!");
Add const DiagnosticBuilder &operator<<(const DiagnosticBuilder &DB, AccessSpecifier AS); so we can easily add access specifiers to diagnostics. llvm-svn: 67795
2009-03-27 07:46:50 +08:00
case AS_public:
return "public";
case AS_private:
return "private";
case AS_protected:
return "protected";
}
Remove unnecessary default cases in switches over enums. This allows -Wswitch-enum to find switches that need updating when these enums are modified. llvm-svn: 148281
2012-01-17 10:30:50 +08:00
llvm_unreachable("Invalid access specifier!");
Add const DiagnosticBuilder &operator<<(const DiagnosticBuilder &DB, AccessSpecifier AS); so we can easily add access specifiers to diagnostics. llvm-svn: 67795
2009-03-27 07:46:50 +08:00
}
const DiagnosticBuilder &clang::operator<<(const DiagnosticBuilder &DB,
AccessSpecifier AS) {
return DB << getAccessName(AS);
}
constexpr: * support the gcc __builtin_constant_p() ? ... : ... folding hack in C++11 * check for unspecified values in pointer comparisons and pointer subtractions llvm-svn: 149578
2012-02-02 09:16:57 +08:00
const PartialDiagnostic &clang::operator<<(const PartialDiagnostic &DB,
AccessSpecifier AS) {
return DB << getAccessName(AS);
}