There were code paths that are duplicated for constructors and destructors just
because we have both CXXCtorType and CXXDtorsTypes.
This patch introduces an unified enum and reduces code deplication a bit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217383 91177308-0d34-0410-b5e6-96231b3b80d8
into EmitCXXMemberOrOperatorCall methods. In the end we want
to make declaration visible in EmitCallArgs() method, that
would allow us to alter CodeGen depending on function/parameter
attributes.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216404 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is a first small step towards passing generic "Expr" instead of
ArgBeg/ArgEnd pair into EmitCallArgs() family of methods. Having "Expr" will
allow us to get the corresponding FunctionDecl and its ParmVarDecls,
thus allowing us to alter CodeGen depending on the function/parameter
attributes.
No functionality change.
Test Plan: regression test suite
Reviewers: rnk
Reviewed By: rnk
Subscribers: aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D4915
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216214 91177308-0d34-0410-b5e6-96231b3b80d8
Thoroughly check for a pointer dereference which yields a glvalue. Look
through casts, comma operators, conditional operators, paren
expressions, etc.
This was originally D4416.
Differential Revision: http://reviews.llvm.org/D4592
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213434 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r213401, r213402, r213403, and r213404.
I accidently committed these changes instead of updating the
differential.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213405 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r211467 which reverted r211408,r211410, it caused
crashes in test/SemaCXX/undefined-internal.cpp for i686-win32 targets.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211473 91177308-0d34-0410-b5e6-96231b3b80d8
This refactors the emission of dynamic_cast and typeid expressions so
that ABI specific knowledge lives in appropriate places. There are
quite a few benefits for having the two implementations share a common
core like sharing logic for optimization opportunities.
While we are at it, clean up the tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211402 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enables clang to generate calls to __RTtypeid when lowering
typeid on win32 targets. Test cases are included.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211223 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements call lower from dynamic_cast to __RTDynamicCast
and __RTCastToVoid. Test cases are included. A feature of note is that
helper function getPolymorphicOffset is placed in such a way that it can
be used by EmitTypeid (to be implemented in a later patch) without being
moved. Details are included as comments directly in the code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210377 91177308-0d34-0410-b5e6-96231b3b80d8
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210137 91177308-0d34-0410-b5e6-96231b3b80d8
elements from {}, rather than value-initializing them. This permits calling an
initializer-list constructor or constructing a std::initializer_list object.
(It would also permit initializing a const reference or rvalue reference if
that weren't explicitly prohibited by other rules.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210091 91177308-0d34-0410-b5e6-96231b3b80d8
trailing elements as a single loop, rather than sometimes emitting a nest of
several loops. This fixes a bug where CodeGen would sometimes try to emit an
expression with the wrong type for the element being initialized. Plus various
other minor cleanups to the IR produced for array new initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210079 91177308-0d34-0410-b5e6-96231b3b80d8
initializing an array unless we need it. Specifically, position the
creation of a new basic block after we've checked all of the cases that
bypass the need for it.
Fixes another leak in test/CodeGen* found by LSan.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207900 91177308-0d34-0410-b5e6-96231b3b80d8
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
This patch refactors microsoft record layout to be more "natural". The
most dominant change is that vbptrs and vfptrs are injected after the
fact. This simplifies the implementation and the math for the offest
for the first base/field after the vbptr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198818 91177308-0d34-0410-b5e6-96231b3b80d8
clang still doesn't emit the right llvm code when initializing multi-D arrays it seems.
For e.g. the following code would still crash for me on Windows 7, 64 bit:
auto f4 = new int[100][200][300]{{{1,2,3}, {4, 5, 6}}, {{10, 20, 30}}};
It seems that the final new loop that iterates through each outermost array and memsets it to zero gets confused with its final ptr arithmetic.
This patch ensures that it converts the pointer to the allocated type (int [200][300]) before incrementing it (instead of using the base type: 'int').
Richard somewhat squeamishly approved the patch (as a quick fix to potentially make it into 3.4) - while exhorting for a more optimized fix in the future. http://llvm-reviews.chandlerc.com/D2398
Thanks Richard!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197294 91177308-0d34-0410-b5e6-96231b3b80d8
list, each element of the initializer list may provide more than one of the
base elements of the array. Be sure to initialize the right type and bump the
array pointer by the right amount.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196995 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
MSVC destroys arguments in the callee from left to right. Because C++
objects have to be destroyed in the reverse order of construction, Clang
has to construct arguments from right to left and destroy arguments from
left to right.
This patch fixes the ordering by reversing the order of evaluation of
all call arguments under the MS C++ ABI.
Fixes PR18035.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2275
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196402 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenABITypes is a wrapper built on top of CodeGenModule that exposes
some of the functionality of CodeGenTypes (held by CodeGenModule),
specifically methods that determine the LLVM types appropriate for
function argument and return values.
I addition to CodeGenABITypes.h, CGFunctionInfo.h is introduced, and the
definitions of ABIArgInfo, RequiredArgs, and CGFunctionInfo are moved
into this new header from the private headers ABIInfo.h and CGCall.h.
Exposing this functionality is one part of making it possible for LLDB
to determine the actual ABI locations of function arguments and return
values, making it possible for it to determine this for any supported
target without hard-coding ABI knowledge in the LLDB code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193717 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r193161.
It broke
void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));
Looks like we have to fix pr17639 first :-(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193162 91177308-0d34-0410-b5e6-96231b3b80d8
names. For example, with this patch we now reject
void f1(void) __attribute__((alias("g1")));
This patch is implemented in CodeGen. It is quiet a bit simpler and more
compatible with gcc than implementing it in Sema. The downside is that the
errors only fire during -emit-llvm.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193161 91177308-0d34-0410-b5e6-96231b3b80d8
The intent of getTypeOperand() was to yield an unqualified type.
However QualType::getUnqualifiedType() does not strip away qualifiers on
arrays.
N.B. This worked fine when typeid() was applied to an expression
because we would inject as implicit cast to the unqualified array type
in the AST.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191487 91177308-0d34-0410-b5e6-96231b3b80d8
They were mostly copy&paste of each other, move it to CodeGenFunction. Of course
the two implementations have diverged over time; the one in CGExprCXX seems to
be the more modern one so I picked that one and moved it to CGClass which feels
like a better home for it. No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189203 91177308-0d34-0410-b5e6-96231b3b80d8
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186828 91177308-0d34-0410-b5e6-96231b3b80d8
optimize, to follow the permissions granted in N3664. Under those rules, only
calls generated by new-expressions and delete-expressions are permitted to be
optimized, and direct calls to ::operator new and ::operator delete must be
treated as normal calls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186799 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies the core benefit of -flimit-debug-info by taking a more
systematic approach to avoid emitting debug info definitions for types
that only require declarations. The previous ad-hoc approach (3 cases
removed in this patch) had many holes.
The general approach (adding a bit to TagDecl and callback through
ASTConsumer) has been discussed with Richard Smith - though always open
to revision.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186262 91177308-0d34-0410-b5e6-96231b3b80d8
This allows clang to use the backend parameter attribute 'returned' when generating 'this'-returning constructors and destructors in ARM and MSVC C++ ABIs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185291 91177308-0d34-0410-b5e6-96231b3b80d8
1) Removed useless return value of CGCXXABI::EmitConstructorCall and CGCXXABI::EmitVirtualDestructorCall and implementations
2) Corrected last portion of CodeGenCXX/constructor-destructor-return-this to correctly test for non-'this'-return of virtual destructor calls
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184330 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183872 91177308-0d34-0410-b5e6-96231b3b80d8
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176656 91177308-0d34-0410-b5e6-96231b3b80d8
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176286 91177308-0d34-0410-b5e6-96231b3b80d8
This can yield dramatic speedups of dynamic_cast for simple inheritance trees,
at least with libsupc++. Neither libcxxabi nor libcxxrt make use of this
hint currently, it was never implemented because clang didn't support it.
There was some concern about the number of class hierarchy walks this change
introduces. If it turns out to be an issue we can add caching either at the cast
pair level or even deeper, but we also do a lot of walks in Sema so this
codepath is probably fairly optimized already.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174293 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
Reported in the thread "devirtualisation appears to crash clang on covariant functions on ARM" on cfe-dev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166651 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a regression from r162254, the optimizer has problems reasoning
about the smaller memcpy as it's often not safe to widen a store but making it
smaller is.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164917 91177308-0d34-0410-b5e6-96231b3b80d8
be sure to delete the complete object pointer, not the original
pointer. This is necessary if the base being deleted is at a
non-zero offset in the complete object. This is only required
for objects with virtual destructors because deleting an object
via a base-class subobject when the base does not have a virtual
destructor is undefined behavior.
Noticed while reviewing the last four years of cxx-abi-dev
activity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164597 91177308-0d34-0410-b5e6-96231b3b80d8
the trap BB out of the individual checks and into a common function, to prepare
for making this code call into a runtime library. Rename the existing EmitCheck
to EmitTypeCheck to clarify it and to move it out of the way of the new
EmitCheck.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163451 91177308-0d34-0410-b5e6-96231b3b80d8
* when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check
* check that references are bound to appropriate storage
* check that 'this' has appropriate storage in member accesses and member function calls
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162523 91177308-0d34-0410-b5e6-96231b3b80d8
in the ABI arrangement, and leave a hook behind so that we can easily
tweak CCs on platforms that use different CCs by default for C++
instance methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159894 91177308-0d34-0410-b5e6-96231b3b80d8
handy. It can be done, but we would have to build a derived-to-base cast
during codegen to compute the correct this pointer.
I will handle covariant returns next.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159350 91177308-0d34-0410-b5e6-96231b3b80d8
the correct this pointer. There is some potential for sharing a bit more
code with canDevirtualizeMemberFunctionCalls, but that can be done in an
independent patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159326 91177308-0d34-0410-b5e6-96231b3b80d8
the member expression is qualified, call the method specified in the code,
not the most derived one we can find.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159219 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159212 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158104 91177308-0d34-0410-b5e6-96231b3b80d8
I'm pretty sure we are in fact doing the right thing here, but someone who knows the standard better should double-check that we are in fact supposed to zero out the member in the given testcase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157138 91177308-0d34-0410-b5e6-96231b3b80d8
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155808 91177308-0d34-0410-b5e6-96231b3b80d8
a complete object, the memcpy needs to use the data size of
the structure instead of its sizeof() value. Fixes PR12204.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153613 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
optional argument passed through the variadic ellipsis)
potentially affects how we need to lower it. Propagate
this information down to the various getFunctionInfo(...)
overloads on CodeGenTypes. Furthermore, rename those
overloads to clarify their distinct purposes, and make
sure we're calling the right one in the right place.
This has a nice side-effect of making it easier to construct
a function type, since the 'variadic' bit is no longer
separable.
This shouldn't really change anything for our existing
platforms, with one minor exception --- we should now call
variadic ObjC methods with the ... in the "right place"
(see the test case), which I guess matters for anyone
running GNUStep on MIPS. Mostly it's just a substantial
clean-up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150788 91177308-0d34-0410-b5e6-96231b3b80d8
Holding the constructor directly makes no sense when list-initialized arrays come into play. The constructor is now held in a CXXConstructExpr, if construction is what is done. The new design can also distinguish properly between list-initialization and direct-initialization, as well as implicit default-initialization constructors and explicit value-initialization constructors. Finally, doing it this way removes redundance from the AST because CXXNewExpr doesn't try to handle both the allocation and the initialization responsibilities.
This breaks the static analysis of new expressions. I've filed PR12014 to track this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150682 91177308-0d34-0410-b5e6-96231b3b80d8
need to provide a 'dominating IP' which is guaranteed to
dominate the (de)activation point but which cannot be avoided
along any execution path from the (de)activation point to
the push-point of the cleanup. Using the entry block is
bad mojo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144276 91177308-0d34-0410-b5e6-96231b3b80d8
possible for that to matter right now, but eventually I think we'll
need to unify this better, and then it might. Also, use a more
efficient looping structure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139788 91177308-0d34-0410-b5e6-96231b3b80d8
synthesized move assignment within an implicitly-defined move
assignment operator, be sure to treat the derived-to-base cast as an
xvalue (rather than an lvalue). Otherwise, we'll end up getting the
wrong constructor.
Optimize a direct call to a trivial move assignment operator to an
aggregate copy, as we do for trivial copy assignment operators, and
update the the assertion in CodeGenFunction::EmitAggregateCopy() to
cope with this optimization.
Fixes PR10860.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139143 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the code duplication of implicit special member handling even worse,
but the cleanup will have to come later. For now, this works.
Follow-up with tests for explicit defaulting and enabling the __has_feature
flag to come.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138821 91177308-0d34-0410-b5e6-96231b3b80d8
really shouldn't be optional. Fix the remaining place where a
temporary was being passed as potentially-aliased memory.
Fixes PR10756.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138627 91177308-0d34-0410-b5e6-96231b3b80d8
the complete destructor and then invoke the global delete
operator. Previously, we would invoke the deleting destructor, which
calls the wrong delete operator. Fixes PR10341.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135021 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
Type::isUnsignedIntegerOrEnumerationType(), which are like
Type::isSignedIntegerType() and Type::isUnsignedIntegerType() but also
consider the underlying type of a C++0x scoped enumeration type.
Audited all callers to the existing functions, switching those that
need to also handle scoped enumeration types (e.g., those that deal
with constant values) over to the new functions. Fixes PR9923 /
<rdar://problem/9447851>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131735 91177308-0d34-0410-b5e6-96231b3b80d8
operators; their semantics are guaranteed by the language.
If someone wants to argue that freestanding compiles shouldn't recognize
this, I might be convinceable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131395 91177308-0d34-0410-b5e6-96231b3b80d8
It can be larger, it can be smaller, it can be signed, whatever. Handle
all the crazy cases with grace and spirit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131378 91177308-0d34-0410-b5e6-96231b3b80d8
As far as I know, this implementation is complete but might be missing a
few optimizations. Exceptions and virtual bases are handled correctly.
Because I'm an optimist, the web page has appropriately been updated. If
I'm wrong, feel free to downgrade its support categories.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130642 91177308-0d34-0410-b5e6-96231b3b80d8
-C++ objects with user-declared constructor don't need zero'ing.
-We can zero-initialize arrays of C++ objects in "bulk" now, in which case don't zero-initialize each object again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130453 91177308-0d34-0410-b5e6-96231b3b80d8
member function, i.e. something of the form 'x.f' where 'f' is a non-static
member function. Diagnose this in the general case. Some of the new diagnostics
are probably worse than the old ones, but we now get this right much more
universally, and there's certainly room for improvement in the diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130239 91177308-0d34-0410-b5e6-96231b3b80d8
Rafael Espindola