2009-02-14 23:20:19 +03:00
|
|
|
//===--- SemaCXXScopeSpec.cpp - Semantic Analysis for C++ scope specifiers-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements C++ semantic analysis for scope specifiers.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "Sema.h"
|
|
|
|
#include "clang/AST/ASTContext.h"
|
2009-05-11 23:58:34 +04:00
|
|
|
#include "clang/AST/DeclTemplate.h"
|
2009-08-06 07:17:00 +04:00
|
|
|
#include "clang/AST/ExprCXX.h"
|
Introduce a representation for types that we referred to via a
qualified name, e.g.,
foo::x
so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.
The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
::foo::bar::x
The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled).
The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).
Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67265 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19 03:18:19 +03:00
|
|
|
#include "clang/AST/NestedNameSpecifier.h"
|
2009-02-14 23:20:19 +03:00
|
|
|
#include "clang/Parse/DeclSpec.h"
|
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2009-07-22 04:28:09 +04:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2009-02-14 23:20:19 +03:00
|
|
|
using namespace clang;
|
|
|
|
|
Introduce a representation for types that we referred to via a
qualified name, e.g.,
foo::x
so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.
The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
::foo::bar::x
The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled).
The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).
Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67265 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19 03:18:19 +03:00
|
|
|
/// \brief Compute the DeclContext that is associated with the given
|
|
|
|
/// scope specifier.
|
2009-07-22 03:53:31 +04:00
|
|
|
///
|
|
|
|
/// \param SS the C++ scope specifier as it appears in the source
|
|
|
|
///
|
|
|
|
/// \param EnteringContext when true, we will be entering the context of
|
|
|
|
/// this scope specifier, so we can retrieve the declaration context of a
|
|
|
|
/// class template or class template partial specialization even if it is
|
|
|
|
/// not the current instantiation.
|
|
|
|
///
|
|
|
|
/// \returns the declaration context represented by the scope specifier @p SS,
|
|
|
|
/// or NULL if the declaration context cannot be computed (e.g., because it is
|
|
|
|
/// dependent and not the current instantiation).
|
|
|
|
DeclContext *Sema::computeDeclContext(const CXXScopeSpec &SS,
|
|
|
|
bool EnteringContext) {
|
Introduce a representation for types that we referred to via a
qualified name, e.g.,
foo::x
so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.
The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
::foo::bar::x
The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled).
The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).
Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67265 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19 03:18:19 +03:00
|
|
|
if (!SS.isSet() || SS.isInvalid())
|
2009-03-18 03:36:05 +03:00
|
|
|
return 0;
|
|
|
|
|
2009-03-27 02:50:42 +03:00
|
|
|
NestedNameSpecifier *NNS
|
2009-03-27 02:56:24 +03:00
|
|
|
= static_cast<NestedNameSpecifier *>(SS.getScopeRep());
|
2009-05-11 23:58:34 +04:00
|
|
|
if (NNS->isDependent()) {
|
|
|
|
// If this nested-name-specifier refers to the current
|
|
|
|
// instantiation, return its DeclContext.
|
|
|
|
if (CXXRecordDecl *Record = getCurrentInstantiationOf(NNS))
|
|
|
|
return Record;
|
2009-07-22 03:53:31 +04:00
|
|
|
|
|
|
|
if (EnteringContext) {
|
|
|
|
if (const TemplateSpecializationType *SpecType
|
|
|
|
= dyn_cast_or_null<TemplateSpecializationType>(NNS->getAsType())) {
|
Improve support for out-of-line definitions of nested templates and
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
2009-08-26 02:51:20 +04:00
|
|
|
// We are entering the context of the nested name specifier, so try to
|
|
|
|
// match the nested name specifier to either a primary class template
|
|
|
|
// or a class template partial specialization.
|
2009-07-22 03:53:31 +04:00
|
|
|
if (ClassTemplateDecl *ClassTemplate
|
|
|
|
= dyn_cast_or_null<ClassTemplateDecl>(
|
|
|
|
SpecType->getTemplateName().getAsTemplateDecl())) {
|
2009-07-30 21:40:51 +04:00
|
|
|
QualType ContextType
|
|
|
|
= Context.getCanonicalType(QualType(SpecType, 0));
|
|
|
|
|
2009-07-22 03:53:31 +04:00
|
|
|
// If the type of the nested name specifier is the same as the
|
|
|
|
// injected class name of the named class template, we're entering
|
|
|
|
// into that class template definition.
|
|
|
|
QualType Injected = ClassTemplate->getInjectedClassNameType(Context);
|
2009-07-30 21:40:51 +04:00
|
|
|
if (Context.hasSameType(Injected, ContextType))
|
2009-07-22 03:53:31 +04:00
|
|
|
return ClassTemplate->getTemplatedDecl();
|
|
|
|
|
2009-07-30 21:40:51 +04:00
|
|
|
// If the type of the nested name specifier is the same as the
|
|
|
|
// type of one of the class template's class template partial
|
|
|
|
// specializations, we're entering into the definition of that
|
|
|
|
// class template partial specialization.
|
|
|
|
if (ClassTemplatePartialSpecializationDecl *PartialSpec
|
|
|
|
= ClassTemplate->findPartialSpecialization(ContextType))
|
|
|
|
return PartialSpec;
|
2009-07-22 03:53:31 +04:00
|
|
|
}
|
Improve support for out-of-line definitions of nested templates and
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
2009-08-26 02:51:20 +04:00
|
|
|
} else if (const RecordType *RecordT
|
|
|
|
= dyn_cast_or_null<RecordType>(NNS->getAsType())) {
|
|
|
|
// The nested name specifier refers to a member of a class template.
|
|
|
|
return RecordT->getDecl();
|
2009-07-22 03:53:31 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2009-05-11 23:58:34 +04:00
|
|
|
}
|
2009-03-27 02:50:42 +03:00
|
|
|
|
|
|
|
switch (NNS->getKind()) {
|
|
|
|
case NestedNameSpecifier::Identifier:
|
|
|
|
assert(false && "Dependent nested-name-specifier has no DeclContext");
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NestedNameSpecifier::Namespace:
|
|
|
|
return NNS->getAsNamespace();
|
|
|
|
|
|
|
|
case NestedNameSpecifier::TypeSpec:
|
|
|
|
case NestedNameSpecifier::TypeSpecWithTemplate: {
|
2009-07-30 01:53:49 +04:00
|
|
|
const TagType *Tag = NNS->getAsType()->getAs<TagType>();
|
2009-03-27 02:50:42 +03:00
|
|
|
assert(Tag && "Non-tag type in nested-name-specifier");
|
|
|
|
return Tag->getDecl();
|
|
|
|
} break;
|
|
|
|
|
|
|
|
case NestedNameSpecifier::Global:
|
|
|
|
return Context.getTranslationUnitDecl();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Required to silence a GCC warning.
|
|
|
|
return 0;
|
2009-03-18 03:36:05 +03:00
|
|
|
}
|
|
|
|
|
Introduce a new expression type, UnresolvedDeclRefExpr, that describes
dependent qualified-ids such as
Fibonacci<N - 1>::value
where N is a template parameter. These references are "unresolved"
because the name is dependent and, therefore, cannot be resolved to a
declaration node (as we would do for a DeclRefExpr or
QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to
DeclRefExprs, QualifiedDeclRefExprs, etc.
Also, be a bit more careful about keeping only a single set of
specializations for a class template, and instantiating from the
definition of that template rather than a previous declaration. In
general, we need a better solution for this for all TagDecls, because
it's too easy to accidentally look at a declaration that isn't the
definition.
We can now process a simple Fibonacci computation described as a
template metaprogram.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67308 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19 20:26:29 +03:00
|
|
|
bool Sema::isDependentScopeSpecifier(const CXXScopeSpec &SS) {
|
|
|
|
if (!SS.isSet() || SS.isInvalid())
|
|
|
|
return false;
|
|
|
|
|
2009-03-27 02:50:42 +03:00
|
|
|
NestedNameSpecifier *NNS
|
2009-03-27 02:56:24 +03:00
|
|
|
= static_cast<NestedNameSpecifier *>(SS.getScopeRep());
|
2009-03-27 02:50:42 +03:00
|
|
|
return NNS->isDependent();
|
Introduce a new expression type, UnresolvedDeclRefExpr, that describes
dependent qualified-ids such as
Fibonacci<N - 1>::value
where N is a template parameter. These references are "unresolved"
because the name is dependent and, therefore, cannot be resolved to a
declaration node (as we would do for a DeclRefExpr or
QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to
DeclRefExprs, QualifiedDeclRefExprs, etc.
Also, be a bit more careful about keeping only a single set of
specializations for a class template, and instantiating from the
definition of that template rather than a previous declaration. In
general, we need a better solution for this for all TagDecls, because
it's too easy to accidentally look at a declaration that isn't the
definition.
We can now process a simple Fibonacci computation described as a
template metaprogram.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67308 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19 20:26:29 +03:00
|
|
|
}
|
|
|
|
|
2009-05-11 23:58:34 +04:00
|
|
|
// \brief Determine whether this C++ scope specifier refers to an
|
|
|
|
// unknown specialization, i.e., a dependent type that is not the
|
|
|
|
// current instantiation.
|
|
|
|
bool Sema::isUnknownSpecialization(const CXXScopeSpec &SS) {
|
|
|
|
if (!isDependentScopeSpecifier(SS))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
NestedNameSpecifier *NNS
|
|
|
|
= static_cast<NestedNameSpecifier *>(SS.getScopeRep());
|
|
|
|
return getCurrentInstantiationOf(NNS) == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief If the given nested name specifier refers to the current
|
|
|
|
/// instantiation, return the declaration that corresponds to that
|
|
|
|
/// current instantiation (C++0x [temp.dep.type]p1).
|
|
|
|
///
|
|
|
|
/// \param NNS a dependent nested name specifier.
|
|
|
|
CXXRecordDecl *Sema::getCurrentInstantiationOf(NestedNameSpecifier *NNS) {
|
|
|
|
assert(getLangOptions().CPlusPlus && "Only callable in C++");
|
|
|
|
assert(NNS->isDependent() && "Only dependent nested-name-specifier allowed");
|
|
|
|
|
2009-07-22 03:53:31 +04:00
|
|
|
if (!NNS->getAsType())
|
|
|
|
return 0;
|
|
|
|
|
2009-07-31 22:32:42 +04:00
|
|
|
QualType T = QualType(NNS->getAsType(), 0);
|
2009-05-11 23:58:34 +04:00
|
|
|
// If the nested name specifier does not refer to a type, then it
|
|
|
|
// does not refer to the current instantiation.
|
|
|
|
if (T.isNull())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
T = Context.getCanonicalType(T);
|
|
|
|
|
|
|
|
for (DeclContext *Ctx = CurContext; Ctx; Ctx = Ctx->getParent()) {
|
|
|
|
// If we've hit a namespace or the global scope, then the
|
|
|
|
// nested-name-specifier can't refer to the current instantiation.
|
|
|
|
if (Ctx->isFileContext())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
// Skip non-class contexts.
|
|
|
|
CXXRecordDecl *Record = dyn_cast<CXXRecordDecl>(Ctx);
|
|
|
|
if (!Record)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// If this record type is not dependent,
|
|
|
|
if (!Record->isDependentType())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
// C++ [temp.dep.type]p1:
|
|
|
|
//
|
|
|
|
// In the definition of a class template, a nested class of a
|
|
|
|
// class template, a member of a class template, or a member of a
|
|
|
|
// nested class of a class template, a name refers to the current
|
|
|
|
// instantiation if it is
|
|
|
|
// -- the injected-class-name (9) of the class template or
|
|
|
|
// nested class,
|
|
|
|
// -- in the definition of a primary class template, the name
|
|
|
|
// of the class template followed by the template argument
|
|
|
|
// list of the primary template (as described below)
|
|
|
|
// enclosed in <>,
|
|
|
|
// -- in the definition of a nested class of a class template,
|
|
|
|
// the name of the nested class referenced as a member of
|
|
|
|
// the current instantiation, or
|
|
|
|
// -- in the definition of a partial specialization, the name
|
|
|
|
// of the class template followed by the template argument
|
|
|
|
// list of the partial specialization enclosed in <>. If
|
|
|
|
// the nth template parameter is a parameter pack, the nth
|
|
|
|
// template argument is a pack expansion (14.6.3) whose
|
2009-07-30 21:50:56 +04:00
|
|
|
// pattern is the name of the parameter pack.
|
|
|
|
// (FIXME: parameter packs)
|
2009-05-11 23:58:34 +04:00
|
|
|
//
|
|
|
|
// All of these options come down to having the
|
|
|
|
// nested-name-specifier type that is equivalent to the
|
|
|
|
// injected-class-name of one of the types that is currently in
|
|
|
|
// our context.
|
2009-07-22 03:53:31 +04:00
|
|
|
if (Context.getCanonicalType(Context.getTypeDeclType(Record)) == T)
|
2009-05-11 23:58:34 +04:00
|
|
|
return Record;
|
|
|
|
|
|
|
|
if (ClassTemplateDecl *Template = Record->getDescribedClassTemplate()) {
|
|
|
|
QualType InjectedClassName
|
|
|
|
= Template->getInjectedClassNameType(Context);
|
|
|
|
if (T == Context.getCanonicalType(InjectedClassName))
|
|
|
|
return Template->getTemplatedDecl();
|
|
|
|
}
|
2009-07-30 21:40:51 +04:00
|
|
|
// FIXME: check for class template partial specializations
|
2009-05-11 23:58:34 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-03-11 19:48:53 +03:00
|
|
|
/// \brief Require that the context specified by SS be complete.
|
|
|
|
///
|
|
|
|
/// If SS refers to a type, this routine checks whether the type is
|
|
|
|
/// complete enough (or can be made complete enough) for name lookup
|
|
|
|
/// into the DeclContext. A type that is not yet completed can be
|
|
|
|
/// considered "complete enough" if it is a class/struct/union/enum
|
|
|
|
/// that is currently being defined. Or, if we have a type that names
|
|
|
|
/// a class template specialization that is not a complete type, we
|
|
|
|
/// will attempt to instantiate that class template.
|
|
|
|
bool Sema::RequireCompleteDeclContext(const CXXScopeSpec &SS) {
|
|
|
|
if (!SS.isSet() || SS.isInvalid())
|
|
|
|
return false;
|
|
|
|
|
2009-07-23 03:48:44 +04:00
|
|
|
DeclContext *DC = computeDeclContext(SS, true);
|
2009-03-11 19:48:53 +03:00
|
|
|
if (TagDecl *Tag = dyn_cast<TagDecl>(DC)) {
|
|
|
|
// If we're currently defining this type, then lookup into the
|
|
|
|
// type is okay: don't complain that it isn't complete yet.
|
2009-07-30 01:53:49 +04:00
|
|
|
const TagType *TagT = Context.getTypeDeclType(Tag)->getAs<TagType>();
|
2009-03-11 19:48:53 +03:00
|
|
|
if (TagT->isBeingDefined())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// The type must be complete.
|
|
|
|
return RequireCompleteType(SS.getRange().getBegin(),
|
|
|
|
Context.getTypeDeclType(Tag),
|
|
|
|
diag::err_incomplete_nested_name_spec,
|
|
|
|
SS.getRange());
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2009-02-14 23:20:19 +03:00
|
|
|
|
|
|
|
/// ActOnCXXGlobalScopeSpecifier - Return the object that represents the
|
|
|
|
/// global scope ('::').
|
|
|
|
Sema::CXXScopeTy *Sema::ActOnCXXGlobalScopeSpecifier(Scope *S,
|
|
|
|
SourceLocation CCLoc) {
|
2009-03-27 02:50:42 +03:00
|
|
|
return NestedNameSpecifier::GlobalSpecifier(Context);
|
2009-02-14 23:20:19 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/// ActOnCXXNestedNameSpecifier - Called during parsing of a
|
|
|
|
/// nested-name-specifier. e.g. for "foo::bar::" we parsed "foo::" and now
|
|
|
|
/// we want to resolve "bar::". 'SS' is empty or the previously parsed
|
|
|
|
/// nested-name part ("foo::"), 'IdLoc' is the source location of 'bar',
|
|
|
|
/// 'CCLoc' is the location of '::' and 'II' is the identifier for 'bar'.
|
|
|
|
/// Returns a CXXScopeTy* object representing the C++ scope.
|
|
|
|
Sema::CXXScopeTy *Sema::ActOnCXXNestedNameSpecifier(Scope *S,
|
|
|
|
const CXXScopeSpec &SS,
|
|
|
|
SourceLocation IdLoc,
|
|
|
|
SourceLocation CCLoc,
|
Improve support for out-of-line definitions of nested templates and
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
2009-08-26 02:51:20 +04:00
|
|
|
IdentifierInfo &II,
|
|
|
|
bool EnteringContext) {
|
2009-03-27 02:50:42 +03:00
|
|
|
NestedNameSpecifier *Prefix
|
2009-03-27 02:56:24 +03:00
|
|
|
= static_cast<NestedNameSpecifier *>(SS.getScopeRep());
|
2009-03-27 02:50:42 +03:00
|
|
|
|
Improve support for out-of-line definitions of nested templates and
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
2009-08-26 02:51:20 +04:00
|
|
|
NamedDecl *SD = LookupParsedName(S, &SS, &II, LookupNestedNameSpecifierName,
|
|
|
|
false, false, SourceLocation(),
|
|
|
|
EnteringContext);
|
2009-02-14 23:20:19 +03:00
|
|
|
|
|
|
|
if (SD) {
|
2009-03-27 02:50:42 +03:00
|
|
|
if (NamespaceDecl *Namespace = dyn_cast<NamespaceDecl>(SD))
|
|
|
|
return NestedNameSpecifier::Create(Context, Prefix, Namespace);
|
|
|
|
|
|
|
|
if (TypeDecl *Type = dyn_cast<TypeDecl>(SD)) {
|
|
|
|
// Determine whether we have a class (or, in C++0x, an enum) or
|
|
|
|
// a typedef thereof. If so, build the nested-name-specifier.
|
2009-03-28 02:10:48 +03:00
|
|
|
QualType T = Context.getTypeDeclType(Type);
|
|
|
|
bool AcceptableType = false;
|
|
|
|
if (T->isDependentType())
|
|
|
|
AcceptableType = true;
|
|
|
|
else if (TypedefDecl *TD = dyn_cast<TypedefDecl>(SD)) {
|
2009-03-27 02:50:42 +03:00
|
|
|
if (TD->getUnderlyingType()->isRecordType() ||
|
|
|
|
(getLangOptions().CPlusPlus0x &&
|
|
|
|
TD->getUnderlyingType()->isEnumeralType()))
|
2009-03-28 02:10:48 +03:00
|
|
|
AcceptableType = true;
|
2009-03-27 02:50:42 +03:00
|
|
|
} else if (isa<RecordDecl>(Type) ||
|
|
|
|
(getLangOptions().CPlusPlus0x && isa<EnumDecl>(Type)))
|
2009-03-28 02:10:48 +03:00
|
|
|
AcceptableType = true;
|
2009-03-27 02:50:42 +03:00
|
|
|
|
2009-03-28 02:10:48 +03:00
|
|
|
if (AcceptableType)
|
2009-03-27 02:50:42 +03:00
|
|
|
return NestedNameSpecifier::Create(Context, Prefix, false,
|
|
|
|
T.getTypePtr());
|
2009-02-14 23:20:19 +03:00
|
|
|
}
|
2009-03-29 03:53:49 +04:00
|
|
|
|
2009-08-26 04:04:55 +04:00
|
|
|
// FIXME: It would be nice to maintain the namespace alias name, then
|
|
|
|
// see through that alias when resolving the nested-name-specifier down to
|
|
|
|
// a declaration context.
|
2009-03-29 03:53:49 +04:00
|
|
|
if (NamespaceAliasDecl *Alias = dyn_cast<NamespaceAliasDecl>(SD))
|
|
|
|
return NestedNameSpecifier::Create(Context, Prefix,
|
|
|
|
Alias->getNamespace());
|
2009-02-14 23:20:19 +03:00
|
|
|
|
|
|
|
// Fall through to produce an error: we found something that isn't
|
|
|
|
// a class or a namespace.
|
Improve support for out-of-line definitions of nested templates and
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
2009-08-26 02:51:20 +04:00
|
|
|
} else if (SS.isSet() && isDependentScopeSpecifier(SS))
|
|
|
|
return NestedNameSpecifier::Create(Context, Prefix, &II);
|
2009-02-14 23:20:19 +03:00
|
|
|
|
|
|
|
// If we didn't find anything during our lookup, try again with
|
|
|
|
// ordinary name lookup, which can help us produce better error
|
|
|
|
// messages.
|
|
|
|
if (!SD)
|
Improve support for out-of-line definitions of nested templates and
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
2009-08-26 02:51:20 +04:00
|
|
|
SD = LookupParsedName(S, &SS, &II, LookupOrdinaryName,
|
|
|
|
false, false, SourceLocation(),
|
|
|
|
EnteringContext);
|
2009-02-14 23:20:19 +03:00
|
|
|
unsigned DiagID;
|
|
|
|
if (SD)
|
|
|
|
DiagID = diag::err_expected_class_or_namespace;
|
|
|
|
else if (SS.isSet())
|
|
|
|
DiagID = diag::err_typecheck_no_member;
|
|
|
|
else
|
|
|
|
DiagID = diag::err_undeclared_var_use;
|
|
|
|
|
|
|
|
if (SS.isSet())
|
|
|
|
Diag(IdLoc, DiagID) << &II << SS.getRange();
|
|
|
|
else
|
|
|
|
Diag(IdLoc, DiagID) << &II;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Implement parsing of nested-name-specifiers that involve template-ids, e.g.,
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65467 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-25 22:37:18 +03:00
|
|
|
Sema::CXXScopeTy *Sema::ActOnCXXNestedNameSpecifier(Scope *S,
|
|
|
|
const CXXScopeSpec &SS,
|
|
|
|
TypeTy *Ty,
|
|
|
|
SourceRange TypeRange,
|
|
|
|
SourceLocation CCLoc) {
|
2009-03-27 02:50:42 +03:00
|
|
|
NestedNameSpecifier *Prefix
|
2009-03-27 02:56:24 +03:00
|
|
|
= static_cast<NestedNameSpecifier *>(SS.getScopeRep());
|
2009-08-19 05:28:28 +04:00
|
|
|
QualType T = GetTypeFromParser(Ty);
|
2009-03-27 02:50:42 +03:00
|
|
|
return NestedNameSpecifier::Create(Context, Prefix, /*FIXME:*/false,
|
2009-05-14 04:28:11 +04:00
|
|
|
T.getTypePtr());
|
Implement parsing of nested-name-specifiers that involve template-ids, e.g.,
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65467 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-25 22:37:18 +03:00
|
|
|
}
|
|
|
|
|
2009-08-06 07:17:00 +04:00
|
|
|
Action::OwningExprResult
|
|
|
|
Sema::ActOnCXXEnterMemberScope(Scope *S, CXXScopeSpec &SS, ExprArg Base,
|
|
|
|
tok::TokenKind OpKind) {
|
2009-08-11 03:49:36 +04:00
|
|
|
// Since this might be a postfix expression, get rid of ParenListExprs.
|
|
|
|
Base = MaybeConvertParenListExprToParenExpr(S, move(Base));
|
|
|
|
|
2009-08-06 07:17:00 +04:00
|
|
|
Expr *BaseExpr = (Expr*)Base.get();
|
|
|
|
assert(BaseExpr && "no record expansion");
|
|
|
|
|
|
|
|
QualType BaseType = BaseExpr->getType();
|
|
|
|
// FIXME: handle dependent types
|
|
|
|
if (BaseType->isDependentType())
|
|
|
|
return move(Base);
|
|
|
|
|
|
|
|
// C++ [over.match.oper]p8:
|
|
|
|
// [...] When operator->returns, the operator-> is applied to the value
|
|
|
|
// returned, with the original second operand.
|
|
|
|
if (OpKind == tok::arrow) {
|
|
|
|
while (BaseType->isRecordType()) {
|
|
|
|
Base = BuildOverloadedArrowExpr(S, move(Base), BaseExpr->getExprLoc());
|
|
|
|
BaseExpr = (Expr*)Base.get();
|
|
|
|
if (BaseExpr == NULL)
|
|
|
|
return ExprError();
|
|
|
|
BaseType = BaseExpr->getType();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (BaseType->isPointerType())
|
|
|
|
BaseType = BaseType->getPointeeType();
|
|
|
|
|
|
|
|
// We could end up with various non-record types here, such as extended
|
|
|
|
// vector types or Objective-C interfaces. Just return early and let
|
|
|
|
// ActOnMemberReferenceExpr do the work.
|
|
|
|
if (!BaseType->isRecordType())
|
|
|
|
return move(Base);
|
|
|
|
|
|
|
|
SS.setRange(BaseExpr->getSourceRange());
|
|
|
|
SS.setScopeRep(
|
|
|
|
NestedNameSpecifier::Create(Context, 0, false, BaseType.getTypePtr())
|
|
|
|
);
|
|
|
|
|
|
|
|
if (S)
|
|
|
|
ActOnCXXEnterDeclaratorScope(S,SS);
|
|
|
|
return move(Base);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Sema::ActOnCXXExitMemberScope(Scope *S, const CXXScopeSpec &SS) {
|
|
|
|
if (S && SS.isSet())
|
|
|
|
ActOnCXXExitDeclaratorScope(S,SS);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-02-14 23:20:19 +03:00
|
|
|
/// ActOnCXXEnterDeclaratorScope - Called when a C++ scope specifier (global
|
|
|
|
/// scope or nested-name-specifier) is parsed, part of a declarator-id.
|
|
|
|
/// After this method is called, according to [C++ 3.4.3p3], names should be
|
|
|
|
/// looked up in the declarator-id's scope, until the declarator is parsed and
|
|
|
|
/// ActOnCXXExitDeclaratorScope is called.
|
|
|
|
/// The 'SS' should be a non-empty valid CXXScopeSpec.
|
|
|
|
void Sema::ActOnCXXEnterDeclaratorScope(Scope *S, const CXXScopeSpec &SS) {
|
|
|
|
assert(SS.isSet() && "Parser passed invalid CXXScopeSpec.");
|
2009-07-22 03:53:31 +04:00
|
|
|
if (DeclContext *DC = computeDeclContext(SS, true))
|
2009-07-21 22:59:28 +04:00
|
|
|
EnterDeclaratorContext(S, DC);
|
2009-02-14 23:20:19 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/// ActOnCXXExitDeclaratorScope - Called when a declarator that previously
|
|
|
|
/// invoked ActOnCXXEnterDeclaratorScope(), is finished. 'SS' is the same
|
|
|
|
/// CXXScopeSpec that was passed to ActOnCXXEnterDeclaratorScope as well.
|
|
|
|
/// Used to indicate that names should revert to being looked up in the
|
|
|
|
/// defining scope.
|
|
|
|
void Sema::ActOnCXXExitDeclaratorScope(Scope *S, const CXXScopeSpec &SS) {
|
|
|
|
assert(SS.isSet() && "Parser passed invalid CXXScopeSpec.");
|
2009-08-26 04:04:55 +04:00
|
|
|
if (SS.isInvalid())
|
|
|
|
return;
|
|
|
|
if (computeDeclContext(SS, true))
|
2009-07-21 22:59:28 +04:00
|
|
|
ExitDeclaratorContext(S);
|
2009-02-14 23:20:19 +03:00
|
|
|
}
|