of any previous declaration in case we replace it in a class's declaration table.
Fixes bug 4858. This sort of thing makes me reconsider putting friend declarations in
declaration lists.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80750 91177308-0d34-0410-b5e6-96231b3b80d8
decl list, and remove some workarounds that were due to this. Thanks to Eli for
pointing this out and providing the test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80745 91177308-0d34-0410-b5e6-96231b3b80d8
declarations of same, introduce a single AST class and add appropriate bits
(encoded in the namespace) for whether a decl is "real" or not. Much hackery
about previously-declared / not-previously-declared, but it's essentially
mandated by the standard that friends alter lookup, and this is at least
fairly non-intrusive.
Refactor the Sema methods specific to friends for cleaner flow and less nesting.
Incidentally solve a few bugs, but I remain confident that we can put them back.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80353 91177308-0d34-0410-b5e6-96231b3b80d8
templates within class templates, producing a member function template
of a class template specialization. If you can parse that, I'm
sorry. Example:
template<typename T>
struct X {
template<typename U> void f(T, U);
};
When we instantiate X<int>, we now instantiate the declaration
X<int>::f, which looks like this:
template<typename U> void X<int>::f(int, U);
The path this takes through
TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and
ugly, but I don't know how to improve it yet. I'm resting my hopes on
the multi-level substitution required to instantiate definitions of
nested templates, which may simplify this code as well.
More testing to come...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80252 91177308-0d34-0410-b5e6-96231b3b80d8
TypenameType if getTypeName is looking at a member of an unknown
specialization. This allows us to properly parse class templates that
derived from type that could only otherwise be described by a typename type,
e.g.,
template<class T> struct X {};
template<typename T> struct Y : public X<T>::X { };
Fixes PR4381.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80123 91177308-0d34-0410-b5e6-96231b3b80d8
qualified name does not actually refer into a class/class
template/class template partial specialization.
Improve printing of nested-name-specifiers to eliminate redudant
qualifiers. Also, make it possible to output a nested-name-specifier
through a DiagnosticBuilder, although there are relatively few places
that will use this leeway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80056 91177308-0d34-0410-b5e6-96231b3b80d8
their members, including member class template, member function
templates, and member classes and functions of member templates.
To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,
template<typename X> template<typename Y>
X Outer<X>::Inner1<Y>::foo(Y) {
return X();
}
we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.
Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80044 91177308-0d34-0410-b5e6-96231b3b80d8
accurately. Prevents the assert from triggering incorrectly when friending
functions first declared in extern "C" contexts. Fixes bug 4757.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80016 91177308-0d34-0410-b5e6-96231b3b80d8
the logic is there for out-of-line definitions with multiple levels of
nested templates, but this is still a work-in-progress: we're having
trouble determining when we should look into a dependent
nested-name-specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80003 91177308-0d34-0410-b5e6-96231b3b80d8
DeclaratorDecl contains a DeclaratorInfo* to keep type source info.
Subclasses of DeclaratorDecl are FieldDecl, FunctionDecl, and VarDecl.
EnumConstantDecl still inherits from ValueDecl since it has no need for DeclaratorInfo.
Decl/Sema interfaces accept a DeclaratorInfo as parameter but no DeclaratorInfo is created yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79392 91177308-0d34-0410-b5e6-96231b3b80d8
This currently breaks test/SemaObjC/id-isa-ref.m and issues some spurious warnings when you attempt to assign a struct objc_class* value to a Class variable. The test case probably should fail as it's written, because without the definition of Class the compiler should not assume struct objc_class* is a valid receiver type, but it's left broken because it would be nice if we could get that passing too for the special case of isa.
Approved by snaroff.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79248 91177308-0d34-0410-b5e6-96231b3b80d8
FriendFunctionDecl, and create instances as appropriate.
The design of FriendFunctionDecl is still somewhat up in the air; you can
befriend arbitrary types of functions --- methods, constructors, etc. ---
and it's not clear that this representation captures that very well.
We'll have a better picture when we start consuming this data in access
control.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78653 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary because #pragma pack and __attribute__((packed)) have different semantics. No functionality change yet, but this lays the groundwork for fixing a record layout bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78483 91177308-0d34-0410-b5e6-96231b3b80d8
we were going to enter into the scope of a class template or class
template partial specialization, rebuild that type so that it can
refer to members of the current instantiation, as in code like
template<typename T>
struct X {
typedef T* pointer;
pointer data();
};
template<typename T>
typename X<T>::pointer X<T>::data() { ... }
Without rebuilding the return type of this out-of-line definition, the
canonical return type of the out-of-line definition (a TypenameType)
will not match the canonical return type of the declaration (the
canonical type of T*).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78316 91177308-0d34-0410-b5e6-96231b3b80d8
elsewhere. Very slightly decouples DeclSpec users from knowing the exact
diagnostics to report, and makes it easier to provide different diagnostics in
some places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77990 91177308-0d34-0410-b5e6-96231b3b80d8
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77510 91177308-0d34-0410-b5e6-96231b3b80d8
Fariborz Jahanian
John McCall
Anders Carlsson
Douglas Gregor
Eli Friedman
Sanjiv Gupta
Argyrios Kyrtzidis
David Chisnall
Edward O'Callaghan
Mike Stump
Ryan Flynn
Ted Kremenek