| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
definition was completed.
llvm-svn: 117240
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
function decls.
Reviewed by rjmccall and nlewycky.
llvm-svn: 116979
|
| |
|
|
|
|
|
|
| |
that a chained PCH writes the definition again.
Thanks to Doug for the hint!
llvm-svn: 116975
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
CXXRecordDecl::DefinitionData, rather than having Sema mark the bit.
llvm-svn: 114993
|
| |
|
|
|
|
| |
<rdar://problem/8459981>.
llvm-svn: 114984
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
one of them) was causing a series of failures:
http://google1.osuosl.org:8011/builders/clang-x86_64-darwin10-selfhost/builds/4518
svn merge -c -114929 https://llvm.org/svn/llvm-project/cfe/trunk
--- Reverse-merging r114929 into '.':
U include/clang/Sema/Sema.h
U include/clang/AST/DeclCXX.h
U lib/Sema/SemaDeclCXX.cpp
U lib/Sema/SemaTemplateInstantiateDecl.cpp
U lib/Sema/SemaDecl.cpp
U lib/Sema/SemaTemplateInstantiate.cpp
U lib/AST/DeclCXX.cpp
svn merge -c -114925 https://llvm.org/svn/llvm-project/cfe/trunk
--- Reverse-merging r114925 into '.':
G include/clang/AST/DeclCXX.h
G lib/Sema/SemaDeclCXX.cpp
G lib/AST/DeclCXX.cpp
svn merge -c -114924 https://llvm.org/svn/llvm-project/cfe/trunk
--- Reverse-merging r114924 into '.':
G include/clang/AST/DeclCXX.h
G lib/Sema/SemaDeclCXX.cpp
G lib/Sema/SemaDecl.cpp
G lib/AST/DeclCXX.cpp
U lib/AST/ASTContext.cpp
svn merge -c -114921 https://llvm.org/svn/llvm-project/cfe/trunk
--- Reverse-merging r114921 into '.':
G include/clang/AST/DeclCXX.h
G lib/Sema/SemaDeclCXX.cpp
G lib/Sema/SemaDecl.cpp
G lib/AST/DeclCXX.cpp
llvm-svn: 114933
|
| |
|
|
|
|
|
|
|
|
|
| |
HasTrivialConstructor, HasTrivialCopyConstructor,
HasTrivialCopyAssignment, and HasTrivialDestructor bits in
CXXRecordDecl's methods. This completes all but the Abstract bit and
the set of conversion functions, both of which will require a bit of
extra work. The majority of <rdar://problem/8459981> is now
implemented (but not all of it).
llvm-svn: 114929
|
| |
|
|
|
|
|
| |
Polymorphic bit in CXXRecordDecl itself. Yes, this is also part of
<rdar://problem/8459981>.
llvm-svn: 114925
|
| |
|
|
|
|
| |
in CXXRecordDecl itself. Yes, this is also part of <rdar://problem/8459981>.
llvm-svn: 114924
|
| |
|
|
|
|
|
| |
and PlainOldData bits in CXXRecordDecl itself. Another milepost on the
road toward <rdar://problem/8459981>.
llvm-svn: 114921
|
| |
|
|
|
|
|
| |
DeclaredDestructor and UserDeclaredDestructor bits in CXXRecordDecl
itself. Another step on the road to <rdar://problem/8459981>.
llvm-svn: 114918
|
| |
|
|
|
|
|
|
| |
already be determined by isCopyAssignmentOperator(), and was set too
late in the process for all clients to see the appropriate
value. Cleanup only; no functionality change.
llvm-svn: 114916
|
| |
|
|
|
|
|
| |
CXXRecordDecl::DefinitionData::DeclaredCopyAssignment, for
copy-assignment operators. Another step toward <rdar://problem/8459981>.
llvm-svn: 114899
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
due to lazy declaration of default constructors. Now that __has_nothrow_constructor doesn't use it anymore, part of PR8101 is fixed.
llvm-svn: 113794
|
| |
|
|
| |
llvm-svn: 112905
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 110912
|
| |
|
|
| |
llvm-svn: 110860
|
| |
|
|
| |
llvm-svn: 109396
|
| |
|
|
| |
llvm-svn: 109380
|
| |
|
|
|
|
| |
since we aren't going to be calling them ever.
llvm-svn: 109377
|
| |
|
|
|
|
|
|
| |
of getBody() when we are just checking the existence of a body, to avoid de-serialization of the body from PCH.
Makes de-serialization of the function body even more "lazier".
llvm-svn: 107768
|
| |
|
|
|
|
| |
instantiated-from information.
llvm-svn: 107597
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations for implicit default constructors, copy constructors,
copy assignment operators, and destructors. On a "simple" translation
unit that includes a bunch of C++ standard library headers, we
generate relatively few of these implicit declarations now:
4/159 implicit default constructors created
18/236 implicit copy constructors created
70/241 implicit copy assignment operators created
0/173 implicit destructors created
And, on this translation unit, this optimization doesn't really
provide any benefit. I'll do some more performance measurements soon,
but this completes the implementation work for <rdar://problem/8151045>.
llvm-svn: 107551
|
| |
|
|
| |
llvm-svn: 107543
|
| |
|
|
| |
llvm-svn: 107521
|
| |
|
|
| |
llvm-svn: 107510
|
| |
|
|
|
|
| |
them for PCH reading.
llvm-svn: 107468
|
| |
|
|
| |
llvm-svn: 107437
|
| |
|
|
| |
llvm-svn: 107429
|
| |
|
|
|
|
| |
copy-assignment operator.
llvm-svn: 107406
|
| |
|
|
|
|
| |
CXXRecordDecl::getDestructor(); no functionality change.
llvm-svn: 107394
|
| |
|
|
| |
llvm-svn: 104712
|
| |
|
|
|
|
| |
getFullSourceRange -> getSourceRange for TypeLoc.
llvm-svn: 104220
|
| |
|
|
| |
llvm-svn: 103517
|
| |
|
|
|
|
| |
Andrew Sutton!
llvm-svn: 103301
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implicitly-generated copy constructor. Previously, Sema would perform
some checking and instantiation to determine which copy constructors,
etc., would be called, then CodeGen would attempt to figure out which
copy constructor to call... but would get it wrong, or poke at an
uninstantiated default argument, or fail in other ways.
The new scheme is similar to what we now do for the implicit
copy-assignment operator, where Sema performs all of the semantic
analysis and builds specific ASTs that look similar to the ASTs we'd
get from explicitly writing the copy constructor, so that CodeGen need
only do a direct translation.
However, it's not quite that simple because one cannot explicit write
elementwise copy-construction of an array. So, I've extended
CXXBaseOrMemberInitializer to contain a list of indexing variables
used to copy-construct the elements. For example, if we have:
struct A { A(const A&); };
struct B {
A array[2][3];
};
then we generate an implicit copy assignment operator for B that looks
something like this:
B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { }
CodeGen will loop over the invented variables i0 and i1 to visit all
elements in the array, so that each element in the destination array
will be copy-constructed from the corresponding element in the source
array. Of course, if we're dealing with arrays of scalars or class
types with trivial copy-assignment operators, we just generate a
memcpy rather than a loop.
Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes
all of its regression tests.
Conspicuously missing from this patch is handling for the exceptional
case, where we need to destruct those objects that we have
constructed. I'll address that case separately.
llvm-svn: 103079
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of a class template or class template partial specialization. That is to
say, in
template <class T> class A { ... };
or
template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context. This allows us to track the
current instantiation appropriately even inside AST routines. It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).
llvm-svn: 102407
|
| |
|
|
|
|
|
|
| |
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
llvm-svn: 101826
|
| |
|
|
|
|
| |
initializes a virtual base or not.
llvm-svn: 101004
|
| |
|
|
| |
llvm-svn: 99979
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
initializing virtual bases in the wrong order.
llvm-svn: 99806
|