template and defined outside it, don't instantiate it twice when instantiating
the surrounding class template specialization. That would cause us to reject
the code because we think two partial specializations instantiated to produce
the same signature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191418 91177308-0d34-0410-b5e6-96231b3b80d8
an additional conversion (other than a qualification conversion) would be
required after the explicit conversion.
Conversely, do allow explicit conversion functions to be used when initializing
a temporary for a reference binding in direct-list-initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191150 91177308-0d34-0410-b5e6-96231b3b80d8
variable from being the function to being the enclosing namespace scope (in
C++) or the TU (in C). This allows us to fix a selection of related issues
where we would build incorrect redeclaration chains for such declarations, and
fail to notice type mismatches.
Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern,
which is only found when searching scopes, and not found when searching
DeclContexts. Such a declaration is only made visible in its DeclContext if
there are no non-LocalExtern declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191064 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When selecting a mangling for an anonymous tag type:
- We should first try it's typedef'd name.
- If that doesn't work, we should mangle in the name of the declarator
that specified it as a declaration specifier.
- If that doesn't work, fall back to a static mangling of
<unnamed-type>.
This should make our anonymous type mangling compatible.
This partially fixes PR16994; we would need to have an implementation of
scope numbering to get it right (a separate issue).
Reviewers: rnk, rsmith, rjmccall, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1540
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190892 91177308-0d34-0410-b5e6-96231b3b80d8
When an AST file is built based on another AST file, it can use a decl from
the fist file, and therefore mark the "isUsed" bit. We need to note this in
the AST file so that the bit is set correctly when the second AST file is
loaded.
This patch introduces the distinction between setIsUsed() and markUsed() so
that we don't call into the ASTMutationListener callback when it wouldn't
be appropriate.
Fixes PR16635.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190016 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We would not perform substitution at an appropriate point, allowing strange
results to appear. We would accepts things that we shouldn't or mangle things incorrectly. Note that this hasn't fixed the other cases like
template-template parameters or non-type template parameters.
Reviewers: doug.gregor, rjmccall, rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1507
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189540 91177308-0d34-0410-b5e6-96231b3b80d8
This was only used to ensure that the traversal order was the same as the
insertion order, but that guarantee was already being provided by the use
of a FoldingSetVector.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189075 91177308-0d34-0410-b5e6-96231b3b80d8
referenced as a member of the current instantiation. In that case, deduce the
type of the function to a dependent type rather than exposing an undeduced auto
type to the rest of the current instantiation.
The standard doesn't really say that the type is dependent in this case; I'll
bring this up with CWG.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188410 91177308-0d34-0410-b5e6-96231b3b80d8
When a local extern declaration redeclares some other entity, the type of that
entity is merged with the prior type if the prior declaration is visible (in C)
or is declared in the same scope (in C++).
- Make LookupRedeclarationWithLinkage actually work in C++, use it in the right
set of cases, and make it track whether it found a shadowed declaration.
- Track whether we found a declaration in the same scope (for C++) including
across serialization and template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188307 91177308-0d34-0410-b5e6-96231b3b80d8
This change unifies the logic for template instantiation of methods and
functions declared with typedefs.
It ensures that SubstFunctionType() always fills the Params out param
with non-null ParmVarDecls or returns null.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1135
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187528 91177308-0d34-0410-b5e6-96231b3b80d8
No functionality change.
In Sema helper functions:
* renamed isTypeName as HasTypenameKeyword
In UsingDecl:
* renamed get/setUsingLocation to get/setUsingLoc
* renamed is/setTypeName as has/setTypename
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186816 91177308-0d34-0410-b5e6-96231b3b80d8
r186331).
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@186546 91177308-0d34-0410-b5e6-96231b3b80d8
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
Richard Smith