| Age | Commit message (Collapse) | Author |
|---|
|
do not look into base classes if there are any dependent base
classes. Instead, note in the lookup result that we couldn't look into
any dependent bases. Use that new result kind to detect when this case
occurs, so that we can fall back to treating the type/value/etc. as a
member of an unknown specialization.
Fixes an issue where we were resolving lookup at template definition
time and then missing an ambiguity at template instantiation time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
finds nothing), and the current instantiation has dependent base
classes, treat the qualified lookup as if it referred to an unknown
specialization. Fixes PR6031.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93433 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
name a template, when they occur in a base-specifier. This is one of
the (few) places where we know for sure that an identifier followed by
a '<' must be a template name, so we can diagnose and recover well:
test/SemaTemplate/dependent-base-classes.cpp:9:16: error: missing
'template'
keyword prior to dependent template name 'T::apply'
struct X1 : T::apply<U> { }; // expected-error{{missing 'template' ...
^
template
test/SemaTemplate/dependent-base-classes.cpp:12:13: error: unknown
template name
'vector'
struct X2 : vector<T> { }; // expected-error{{unknown template name
'vector'}}
^
2 diagnostics generated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93257 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
context, do not attempt typo correction. This harms performance (as
Abramo noted) and can cause some amusing errors, as in this new
testcase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93240 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
were performing name lookup for template names in C/ObjC and always
finding nothing. Turn off such lookup unless we're in C++ mode, along
with the check that determines whether the given identifier is a
"current class name", and assert that we don't make this mistake
again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93207 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(C++ [temp.mem]p5-6), which involves template argument deduction based
on the type named, e.g., given
struct X { template<typename T> operator T*(); } x;
when we call
x.operator int*();
we perform template argument deduction to determine that T=int. This
template argument deduction is needed for template specialization and
explicit instantiation, e.g.,
template<> X::operator float*() { /* ... */ }
and when calling or otherwise naming a conversion function (as in the
first example).
This fixes PR5742 and PR5762, although there's some remaining ugliness
that's causing out-of-line definitions of conversion function
templates to fail. I'll look into that separately.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93162 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointing to the declaration that we found that has that name (if it is
unique).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
typo.cpp:27:8: error: no template named 'basic_sting' in namespace 'std';
did you mean 'basic_string'?
std::basic_sting<char> b2;
~~~~~^~~~~~~~~~~
basic_string
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
accurate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92018 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
explicitly-specified template arguments are enough to determine the
instantiation, and either template argument deduction fails or is not
performed in that context, we can resolve the template-id down to a
function template specialization (so sayeth C++0x
[temp.arg.explicit]p3). Fixes PR5811.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91852 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91678 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
problems on LLVM-Code-Syntax. This proved remarkably easy to "fix" once
I settled on how I was going to approach it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91633 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specifiers for out-of-line declarations, e.g.
typedef Temp<int> MyTemp;
template <> MyTemp::foo;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91395 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
no extra safety anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91207 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variables,
but the results are imperfect.
For posterity, I did:
cat <<EOF > $cmdfile
s/DeclaratorInfo/TypeSourceInfo/g
s/DInfo/TInfo/g
s/TypeTypeSourceInfo/TypeSourceInfo/g
s/SourceTypeSourceInfo/TypeSourceInfo/g
EOF
find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \;
find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \;
find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90743 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90710 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LookupResult::getAsSingleDecl() is no more. Shift Sema::LookupSingleName to
return null on overloaded results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90309 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
leaked data structure than before. This kills off the last remaining
explicit uses of OverloadedFunctionDecl in Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90306 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
there's nothing interesting we can say now that we're correctly not requiring
the qualifier to name a known base class in dependent contexts.
Require scope specifiers on member access expressions to name complete types
if they're not dependent; delay lookup when they are dependent.
Use more appropriate diagnostics when qualified implicit member access
expressions find declarations from unrelated classes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90289 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
implicit member access to a specific declaration, go ahead and create
it as a DeclRefExpr or a MemberExpr (with implicit CXXThisExpr base) as
appropriate. Otherwise, create an UnresolvedMemberExpr or
DependentScopeMemberExpr with a null base expression.
By representing implicit accesses directly in the AST, we get the ability
to correctly delay the decision about whether it's actually an instance
member access or not until resolution is complete. This permits us
to correctly avoid diagnosing the 'problem' of 'MyType::foo()'
where the relationship to the type isn't really known until instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90266 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
those associated with TemplateNames.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90162 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function names outside of templates - they'll probably cause some damage there as
they're largely untested.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90064 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90044 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90030 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the linkage of a declaration. Switch the lame (and completely wrong)
NamedDecl::hasLinkage() over to using the new NamedDecl::getLinkage(),
along with the "can this declaration be a template argument?" check
that started all of this.
Fixes -fsyntax-only for PR5597.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89874 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function templates (in C++98), friend function templates, and
out-of-line definitions of members of class templates.
Also handles merging of default template arguments from previous
declarations of function templates, for C++0x. However, we don't yet
make use of those default template arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89872 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instantiation. lib/Support/CommandLine.cpp is our test case
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89845 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
member-reference contexts. Fixes some clang-on-clang asserts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89796 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
DependentScopeDeclRefExpr support storing templateids. Unite the common
code paths between ActOnDeclarationNameExpr and ActOnTemplateIdExpr.
This gets us to a point where we don't need to store function templates in
the AST using TemplateNames, which is critical to ripping out OverloadedFunction.
Also resolves a few FIXMEs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89785 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
definition so that the function will have the right linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89740 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
complaint to a warning and providing a helpful node in the case where
the "template<>" header is redundant because the corresponding
template-id refers to an explicit specialization. C++0x might still
change this behavior, and existing practice is all over the place on
the number of "template<>" headers actually needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89651 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
locations" into
a new class. Use it pervasively throughout Sema.
My fingers hurt.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89638 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
definition of a member template (or a member thereof). Fixes PR5566.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89512 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
appropriate lookup and simply can't resolve the referrent yet, and
"dependent scope" expressions, where we can't do the lookup yet because the
entity we need to look into is a dependent type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89402 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rather than NamedDecl*. This is a major step towards eliminating
OverloadedFunctionDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89263 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89199 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89184 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
be complete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89042 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LookupResult RAII powers to diagnose ambiguity in the results. Other diagnostics
(e.g. access control and deprecation) will be moved to automatically trigger
during lookup as part of this same mechanism.
This abstraction makes it much easier to encapsulate aliasing declarations
(e.g. using declarations) inside the lookup system: eventually, lookup will
just produce the aliases in the LookupResult, and the standard access methods
will naturally strip the aliases off.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89027 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-type template parameters or constants of pointer-to-member
type. Once checked, be sure to retain those pointer-to-member
constants as expressions if they are dependent, or as declarations if
they are not dependent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@87010 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Comparing template parameter lists to determine if we have a redeclaration
- Comparing template parameter lists to determine if we have equivalent
template template parameters
- Comparing template parameter lists to determine whether a template
template argument is valid for a given template template parameter.
Previously, we did not distinguish between the last two cases, which
got us into trouble when we were looking for exact type matches
between the types of non-type template parameters that were dependent
types. Now we do, so we properly delay checking of template template
arguments until instantiation time.
Also, fix an accidental fall-through in a case statement that was
causing crashes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86992 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template template parameter.
When building a template-id type, check whether the template-name
itself is dependent (even if the template arguments are not!) and
handle it as a template-id type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86913 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
permits, among other things, ripping apart and reconstructing
templates via partial specialization:
template<typename T>
struct DeepRemoveConst { typedef T type; };
template<typename T>
struct DeepRemoveConst<const T> {
typedef typename DeepRemoveConst<T>::type type;
};
template<template<typename> class TT, typename T>
struct DeepRemoveConst<TT<T> > {
typedef TT<typename DeepRemoveConst<T>::type> type;
};
Also, fix a longstanding thinko in the code handling partial ordering
of class template partial specializations. We were performing the
second deduction without clearing out the results of the first
deduction. It's amazing we got through so much code with such a
horrendous error :(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86893 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
with its corresponding template parameter. This can happen when we
performed some substitution into the default template argument and
what we had doesn't match any more, e.g.,
template<int> struct A;
template<typename T, template<T> class X = A> class B;
B<long> b;
Previously, we'd emit a pretty but disembodied diagnostic showing how
the default argument didn't match the template parameter. The
diagnostic was good, but nothing tied it to the *use* of the default
argument in "B<long>". This commit fixes that.
Also, tweak the counting of active template instantiations to avoid
counting non-instantiation records, such as those we create for
(surprise!) checking default arguments, instantiating default
arguments, and performing substitutions as part of template argument
deduction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86884 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template-type-parameter specific template argument checking code and
up to the template argument checking loop. In theory, this should make
variadic templates work better; in practice, they don't well enough
for us to care anyway (YET!), so this is mostly a re-organization to
simplify CheckTemplateArgument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86868 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
increase sanity. No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86866 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template template parameter, substitute any prior template arguments
into the template template parameter. This, for example, allows us to
properly check the template template argument for a class such as:
template<typename T, template<T Value> class X> struct Foo;
The actual implementation of this feature was trivial; most of the
change is dedicated to giving decent diagnostics when this
substitution goes horribly wrong. We now get a note like:
note: while substituting prior template arguments into template
template parameter 'X' [with T = float]
As part of this change, enabled some very pedantic checking when
comparing template template parameter lists, which shook out a bug in
our overly-eager checking of default arguments of template template
parameters. We now perform only minimal checking of such default
arguments when they are initially parsed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86864 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parameters. Rather than storing them as either declarations (for the
non-dependent case) or expressions (for the dependent case), we now
(always) store them as TemplateNames.
The primary change here is to add a new kind of TemplateArgument,
which stores a TemplateName. However, making that change ripples to
every switch on a TemplateArgument's kind, also affecting
TemplateArgumentLocInfo/TemplateArgumentLoc, default template
arguments for template template parameters, type-checking of template
template arguments, etc.
This change is light on testing. It should fix several pre-existing
problems with template template parameters, such as:
- the inability to use dependent template names as template template
arguments
- template template parameter default arguments cannot be
instantiation
However, there are enough pieces missing that more implementation is
required before we can adequately test template template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86777 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handling template template parameters properly. This refactoring:
- Parses template template arguments as id-expressions, representing
the result of the parse as a template name (Action::TemplateTy)
rather than as an expression (lame!).
- Represents all parsed template arguments via a new parser-specific
type, ParsedTemplateArgument, which stores the kind of template
argument (type, non-type, template) along with all of the source
information about the template argument. This replaces an ad hoc
set of 3 vectors (one for a void*, which was either a type or an
expression; one for a bit telling whether the first was a type or
an expression; and one for a single source location pointing at
the template argument).
- Moves TemplateIdAnnotation into the new Parse/Template.h. It never
belonged in the Basic library anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86708 91177308-0d34-0410-b5e6-96231b3b80d8
|
