|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| | llvm-svn: 104733 | 
| | 
| 
| 
| | llvm-svn: 104712 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | VTableUse array if we promote a vtable from being just used to having its definition required. This ensures that we properly inform the consumer about whether the vtable is required or not, previously we could fail to do so when the vtable was in the VTableUses array before the decl which marked it as required.
 - I think this can be cleaned up, since this means we may notify the consumer about the vtable twice, but I didn't see an easy fix for this without more substantial refactoring.
 - Doug, please review!
llvm-svn: 104577 | 
| | 
| 
| 
| | llvm-svn: 104576 | 
| | 
| 
| 
| | llvm-svn: 104445 | 
| | 
| 
| 
| | llvm-svn: 104299 | 
| | 
| 
| 
| 
| 
| | classes whose base class have GC'able object pointers.
llvm-svn: 104296 | 
| | 
| 
| 
| 
| 
| 
| 
| | recursively, e.g. so that members of anonymous unions inside anonymous structs
still get initialized.  Also generate default constructor calls for anonymous
struct members when necessary.
llvm-svn: 104292 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | capture failures when we try to initialize an incomplete
type. Previously, we would (ab)use FK_ConversionFailed, then
occasionally dereference a null pointer when trying to diagnose the
failure. Fixes <rdar://problem/7959007>.
llvm-svn: 104286 | 
| | 
| 
| 
| 
| 
| | getFullSourceRange -> getSourceRange for TypeLoc.
llvm-svn: 104220 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | instance variables:
  - Use isRecordType() rather than isa<RecordType>(), so that we see
  through typedefs in ivar types.
  - Mark the destructor as referenced
  - Perform C++ access control on the destructor
llvm-svn: 104206 | 
| | 
| 
| 
| | llvm-svn: 104169 | 
| | 
| 
| 
| 
| 
| 
| | to mark its destructors as referenced which may cause 
a crash. Fixes radar 7896920
llvm-svn: 103953 | 
| | 
| 
| 
| 
| 
| 
| | function's definition is an out-of-class definition marked
"inline". Fixes an assertion in WebKit.
llvm-svn: 103763 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | "used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions. 
The new scheme:
  - For every use of a vtable, Sema calls MarkVTableUsed() to indicate
  the use. For example, this occurs when calling a virtual member
  function of the class, defining a constructor of that class type,
  dynamic_cast'ing from that type to a derived class, casting
  to/through a virtual base class, etc.
  - For every definition of a vtable, Sema calls MarkVTableUsed() to
  indicate the definition. This happens at the end of the translation
  unit for classes whose key function has been defined (so we can
  delay computation of the key function; see PR6564), and will also
  occur with explicit template instantiation definitions.
 - For every vtable defined/used, we mark all of the virtual member
 functions of that vtable as defined/used, unless we know that the key
 function is in another translation unit. This instantiates virtual
 member functions when needed.
  - At the end of the translation unit, Sema tells CodeGen (via the
  ASTConsumer) which vtables must be defined (CodeGen will define
  them) and which may be used (for which CodeGen will define the
  vtables lazily). 
From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).
Notes:
  (1) There's a ton of churn in the tests, because the order in which
  vtables get emitted to IR has changed. I've tried to isolate some of
  the larger tests from these issues.
  (2) Some diagnostics related to
  implicitly-instantiated/implicitly-defined virtual member functions
  have moved to the point of first use/definition. It's better this
  way.
  (3) I could use a review of the places where we MarkVTableUsed, to
  see if I missed any place where the language effectively requires a
  vtable.
Fixes PR7114 and PR6564.
llvm-svn: 103718 | 
| | 
| 
| 
| | llvm-svn: 103670 | 
| | 
| 
| 
| 
| 
| 
| 
| | member function (default constructor, copy constructor, copy
assignment operator, destructor), emit a note showing where that
implicit definition was required.
llvm-svn: 103619 | 
| | 
| 
| 
| | llvm-svn: 103517 | 
| | 
| 
| 
| 
| 
| | implicitly-instantiated class as ...", which seems to have broken bootstrap.
llvm-svn: 103515 | 
| | 
| 
| 
| 
| 
| 
| 
| | referenced unless we see one of them defined (or the key function
defined, if it as one) or if we need the vtable for something. Fixes
PR7114.
llvm-svn: 103497 | 
| | 
| 
| 
| 
| 
| | scope. Thanks to Steven Watanabe for correcting me.
llvm-svn: 103210 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | different tag kind ("struct" vs. "class") than the primary template,
which has an affect on access control.
Should fix the last remaining Boost.Accumulors failure.
llvm-svn: 103144 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | provide a note that shows where the copy-assignment operator was
needed. We used to have this, but I broke it during refactoring. 
Finishes PR6999.
llvm-svn: 103127 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | implicitly-defined copy assignment operator, suppress the protected
access check. This eliminates the remaining failure in the
Boost.SmartPtr library (that was a product of the copy-assignment
generation rewrite) and, presumably, the Boost.TR1 library as well.
llvm-svn: 103010 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | not just the inner expression.  This is important if the expression has any
temporaries.  Fixes PR 7028.
Basically a symptom of really tragic method names.
llvm-svn: 102998 | 
| | 
| 
| 
| 
| 
| 
| 
| | (-Wunused-exception-parameter) than normal variables, since it's more
common to name and then ignore an exception parameter. This warning is
neither enabled by default nor by -Wall. Fixes <rdar://problem/7931045>.
llvm-svn: 102931 | 
| | 
| 
| 
| 
| 
| | of a base class, give it real source-location information. Fixes PR7017.
llvm-svn: 102916 | 
| | 
| 
| 
| 
| 
| | aren't in scope. Fixes PR7014.
llvm-svn: 102915 | 
| | 
| 
| 
| | llvm-svn: 102902 | 
| | 
| 
| 
| 
| 
| | expression constructs a non-virtual or virtual base.
llvm-svn: 102879 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| | initialize the bases.
llvm-svn: 102842 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | information required to implicitly define a C++ special member
function. Use it rather than explicitly setting CurContext on entry
and exit, which is fragile. 
Use this RAII object for the implicitly-defined default constructor,
copy constructor, copy assignment operator, and destructor.
llvm-svn: 102840 | 
| | 
| 
| 
| 
| 
| 
| | already knows what context it's looking in.  Just pass that context in
instead of (questionably) recalculating it.
llvm-svn: 102818 | 
| | 
| 
| 
| 
| 
| | ivar of c++ object types.
llvm-svn: 102500 | 
| | 
| 
| 
| 
| 
| | with a qualifier referencing a different type.
llvm-svn: 102409 | 
| | 
| 
| 
| | llvm-svn: 102289 | 
| | 
| 
| 
| | llvm-svn: 102283 | 
| | 
| 
| 
| 
| 
| | implicit base initializers. (Member initializers are still handled by CodeGenFunction::SynthesizeCXXCopyConstructor for now).
llvm-svn: 102279 | 
| | 
| 
| 
| 
| 
| | points to the exact base specifier.
llvm-svn: 102277 | 
| | 
| 
| 
| | llvm-svn: 102259 | 
| | 
| 
| 
| 
| 
| | functionality change yet.
llvm-svn: 102250 | 
| | 
| 
| 
| 
| 
| 
| | (e.g., no typename, enum, class, etc.), e.g., because the context is
one that is known to refer to a type. Patch from Enea Zaffanella!
llvm-svn: 102243 | 
| | 
| 
| 
| | llvm-svn: 102179 | 
| | 
| 
| 
| | llvm-svn: 102178 | 
| | 
| 
| 
| 
| 
| | BuildImplicitBaseInitializer and BuildImplicitMemberInitializer.
llvm-svn: 102166 | 
| | 
| 
| 
| | llvm-svn: 102165 | 
| | 
| 
| 
| | llvm-svn: 102162 | 
| | 
| 
| 
| 
| 
| | code. Make BuildImplicitBaseInitializer return a boolean instead.
llvm-svn: 102159 |