declaration. This PCH a little lazier, and breaks a deserialization cycle that
causes crashes with modules enabled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184904 91177308-0d34-0410-b5e6-96231b3b80d8
As noted by Richard in the post:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130624/082605.html, the following code should not add an entry
into PendingLocalImplicitInstantiations, since local instantiations
should only occur within the context of other instantiations:
int foo(double y) {
struct Lambda {
template<class T> T operator()(T t) const { return t; };
} lambda;
return lambda(y);
}
Hence the attached code does the following:
1) In MarkFunctionReferenced, check if ActiveInstantiations.size()
is non-zero before adding to PendingLocalImplicitInstantiations.
2) In InstantiateFunctionDefinition, we swap out/in
PendingLocalImplicitInstantiations so that only those
pending local instantiations that are added during the instantiation
of the current function are instantiated recursively.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184903 91177308-0d34-0410-b5e6-96231b3b80d8
Friend declarations that specify a default argument must be a definition
and the only declaration in the translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184889 91177308-0d34-0410-b5e6-96231b3b80d8
When the decl that we're getting alignment for is a FieldDecl, and the field's
parent record is invalid, skip the actual field alignment calculation (and
return 1-byte alignment in the general case).
Also, assert in in getASTRecordLayout that the decl is valid. This was
inspired by PR16292; see also r184581 and r184751.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184883 91177308-0d34-0410-b5e6-96231b3b80d8
A default template-argument shall not be specified in a friend template
declaration.
Interestingly, we properly handled default template arguments on friend
class members but not on just friend classes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184882 91177308-0d34-0410-b5e6-96231b3b80d8
this code. These aren't technically standard predefines for the platform
but apparantly lots of folks use them as they show up within LLVM's own
codebase. ;] This may even fix some self host issues w/ the JIT!!!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184830 91177308-0d34-0410-b5e6-96231b3b80d8
This test doesn't actually pass when run with llvm-lit for me or in
a bot that actually always tries to run it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184817 91177308-0d34-0410-b5e6-96231b3b80d8
Re-apply r184511, reverted in r184561, with the trivial default constructor
fast path removed -- it turned out not to be necessary here.
Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.
<rdar://problem/14212563>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184815 91177308-0d34-0410-b5e6-96231b3b80d8
In order to make sure virtual base classes are always initialized once,
the AST contains initializers for the base class in /all/ of its
descendents, not just the immediate descendents. However, at runtime,
the most-derived object is responsible for initializing all the virtual
base classes; all the other initializers will be ignored.
The analyzer now checks to see if it's being called from another base
constructor, and if so does not perform virtual base initialization.
<rdar://problem/14236851>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184814 91177308-0d34-0410-b5e6-96231b3b80d8
numbers as we deserialize class template partial specializations. We can't
assume that the old sequence numbers will work.
The sequence numbers are still deterministic, but are now a lot less
predictable for class template partial specializations in modules/PCH.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184811 91177308-0d34-0410-b5e6-96231b3b80d8
Using "delete" on a pointer to an incomplete type can't throw.
While I'm here, clean up the signature of the canCalleeThrow() helper.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184810 91177308-0d34-0410-b5e6-96231b3b80d8
Use castAs<> where appropriate. Don't check conditionals which are
always true. Delete a bit of dead code. Reindent a bunch of code which
is no longer guarded by an if statement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184801 91177308-0d34-0410-b5e6-96231b3b80d8
Rafael Espindola
Nico Weber
Richard Smith
Faisal Vali
Nick Lewycky
David Majnemer
Matt Beaumont-Gay
Fariborz Jahanian
Eli Bendersky
Chandler Carruth
Jordan Rose
Eli Friedman
Eric Christopher