This breaks the build of basic patterns with repeated friend
declarations. See the added test case in SemaCXX/friend.cpp or the test
case reported to the original commit log.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186331 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186199 91177308-0d34-0410-b5e6-96231b3b80d8
fix is.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186185 91177308-0d34-0410-b5e6-96231b3b80d8
lookup in the surrounding context. Slightly rework how we handle friend
declarations to inherit the visibility of the prior declaration, rather
than setting a friend declaration to be visible whenever there was a prior
declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186040 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces a long list of declarations for visitor functions with
a list generated from DeclNodes.inc. Nothing really interesting came
out of it; we had comprehensive coverage anyway
(excluding FriendTemplateDecls).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185118 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
places which weren't setting it up properly. This allows us to get the right
cv-qualifiers for 'this' when it appears outside a method body in a class
template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183483 91177308-0d34-0410-b5e6-96231b3b80d8
instantiate the inherited constructor template and mark that as the constructor
which the instantiated specialization is inheriting. This fixes a
crash-on-valid when trying to compute the exception specification of a
specialization of the inheriting constructor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182072 91177308-0d34-0410-b5e6-96231b3b80d8
Missing (somewhat ironically) is support for the new deduction rules
in lambda functions, plus PCH support for return type patching.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181108 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes pr15753. This is another case of the fuzzy definition of the
"as written" storage class of an instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179581 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179521 91177308-0d34-0410-b5e6-96231b3b80d8
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178663 91177308-0d34-0410-b5e6-96231b3b80d8
just using ASTConsumer::HandleCXXStaticMemberVarInstantiation(), don't pass it with
ASTConsumer::HandleTopLevelDecl.
ASTConsumer::HandleTopLevelDecl is intended for user-written top-level decls;
a consumer can treat an instantiated static data member however it wants of course.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175976 91177308-0d34-0410-b5e6-96231b3b80d8
the normal attribute-merging path, because we can't merge alignment attributes
without knowing the complete set of alignment attributes which apply to a
particular declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175861 91177308-0d34-0410-b5e6-96231b3b80d8
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175462 91177308-0d34-0410-b5e6-96231b3b80d8
Remove "IsMSDeclspec" argument from Align attribute since the arguments in Attr.td should
only model those appear in source code. Introduce attribute Accessor, and teach TableGen
to generate syntax kind accessors for Align attribute, and use those accessors to decide
if an alignment attribute is a declspec attribute.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174133 91177308-0d34-0410-b5e6-96231b3b80d8
for template instantiations, and use it to simplify the implementation of
FunctionDecl::isInlined().
This incidentally changes the result of isInlined on a declared-but-not-defined
non-inline member function from true to false. This is sort of a bug fix, but
currently isInlined is only called on function definitions, so it has no visible
effects.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173397 91177308-0d34-0410-b5e6-96231b3b80d8
copy-list-initialization (and doesn't add an additional copy step):
Fill in the ListInitialization bit when creating a CXXConstructExpr. Use it
when instantiating initializers in order to correctly handle instantiation of
copy-list-initialization. Teach TreeTransform that function arguments are
initializations, and so need this special treatment too. Finally, remove some
hacks which were working around SubstInitializer's shortcomings.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170489 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170482 91177308-0d34-0410-b5e6-96231b3b80d8
definition, rather than at the end of the definition of the set of nested
classes. We still defer checking of the user-specified exception specification
to the end of the nesting -- we can't check that until we've parsed the
in-class initializers for non-static data members.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169805 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169667 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
Chandler Carruth