summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Implement access control for overloaded functions. Suppress access controlJohn McCall2010-01-271-17/+23
| | | | | | | diagnostics in "early" lookups, such as during typename checks and when building unresolved lookup expressions. llvm-svn: 94647
* Create function, block, and template parameters in the context of theJohn McCall2010-01-221-5/+6
| | | | | | | | | translation unit. This is temporary for function and block parameters; template parameters can just stay this way, since Templates aren't DeclContexts. This gives us the nice property that everything created in a record DC should have access in C++. llvm-svn: 94122
* Teach Sema::ActOnDependentTemplateName that a dependent template nameDouglas Gregor2010-01-191-5/+9
| | | | | | | | in a member access expression referring into the current instantiation need not be resolved at template definition *if* the current instantiation has any dependent base classes. Fixes PR6081. llvm-svn: 93877
* When performing qualified name lookup into the current instantiation,Douglas Gregor2010-01-151-8/+4
| | | | | | | | | | | | | 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. llvm-svn: 93497
* When qualified lookup into the current instantiation fails (because itDouglas Gregor2010-01-141-3/+15
| | | | | | | | finds nothing), and the current instantiation has dependent base classes, treat the qualified lookup as if it referred to an unknown specialization. Fixes PR6031. llvm-svn: 93433
* Improve recovery for template-ids whose template-name doesn't actuallyDouglas Gregor2010-01-121-0/+24
| | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 93257
* When determining whether a given name is a template in a dependentDouglas Gregor2010-01-121-2/+3
| | | | | | | | context, do not attempt typo correction. This harms performance (as Abramo noted) and can cause some amusing errors, as in this new testcase. llvm-svn: 93240
* Eliminate an embarrassing performance regression in C/ObjC, where weDouglas Gregor2010-01-111-0/+2
| | | | | | | | | | 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. llvm-svn: 93207
* Implement name lookup for conversion function template specializationsDouglas Gregor2010-01-111-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | (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. llvm-svn: 93162
* Whenever we emit a typo-correction diagnostic, also emit a noteDouglas Gregor2010-01-071-0/+3
| | | | | | | pointing to the declaration that we found that has that name (if it is unique). llvm-svn: 92877
* Typo correction for template names, e.g.,Douglas Gregor2009-12-311-1/+25
| | | | | | | | | | 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 llvm-svn: 92348
* Fix the overflow calculation in Sema::CheckTemplateArgument to be a bit moreEli Friedman2009-12-231-1/+8
| | | | | | accurate. llvm-svn: 92018
* When a template-id refers to a single function template, and theDouglas Gregor2009-12-211-0/+3
| | | | | | | | | | 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. llvm-svn: 91852
* Set up the semantic context correctly when declaring a friend class template.John McCall2009-12-181-4/+5
| | | | llvm-svn: 91678
* Patch over yet more problems with friend declarations which were provokingJohn McCall2009-12-171-23/+23
| | | | | | | problems on LLVM-Code-Syntax. This proved remarkably easy to "fix" once I settled on how I was going to approach it. llvm-svn: 91633
* Diagnose the use of typedefs for template specialization types in the scopeJohn McCall2009-12-151-1/+20
| | | | | | | | specifiers for out-of-line declarations, e.g. typedef Temp<int> MyTemp; template <> MyTemp::foo; llvm-svn: 91395
* Un-namespace-qualify llvm_unreachable. It's a macro, so the qualification gaveJeffrey Yasskin2009-12-121-6/+6
| | | | | | no extra safety anyway. llvm-svn: 91207
* DeclaratorInfo -> TypeSourceInfo. Makes an effort to rename associated ↵John McCall2009-12-071-19/+19
| | | | | | | | | | | | | | | | | | | | | 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 '{}' \; llvm-svn: 90743
* remove some extraneous syntax: sourceloc implicitly converts to sourcerange.Chris Lattner2009-12-061-2/+1
| | | | llvm-svn: 90710
* Rip out the last remaining implicit use of OverloadedFunctionDecl in Sema:John McCall2009-12-021-2/+1
| | | | | | | LookupResult::getAsSingleDecl() is no more. Shift Sema::LookupSingleName to return null on overloaded results. llvm-svn: 90309
* Push overloaded function templates through the parser using a totally differentJohn McCall2009-12-021-27/+27
| | | | | | | leaked data structure than before. This kills off the last remaining explicit uses of OverloadedFunctionDecl in Sema. llvm-svn: 90306
* Stop trying to analyze class-hierarchies for dependently-scoped id-expressions;John McCall2009-12-021-105/+9
| | | | | | | | | | | | | 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. llvm-svn: 90289
* Rework how we support C++ implicit member accesses. If we can resolve anJohn McCall2009-12-011-3/+3
| | | | | | | | | | | | | | | 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. llvm-svn: 90266
* Remove all of Sema's explicit uses of OverloadedFunctionDecl except forJohn McCall2009-11-301-37/+0
| | | | | | those associated with TemplateNames. llvm-svn: 90162
* Add DeclarationName support for C++0x operator literals. They should now work asAlexis Hunt2009-11-291-2/+2
| | | | | | | function names outside of templates - they'll probably cause some damage there as they're largely untested. llvm-svn: 90064
* Remove remaining VISIBILITY_HIDDEN from anonymous namespaces.Benjamin Kramer2009-11-281-2/+1
| | | | llvm-svn: 90044
* Fix test and handle IK_LiteralOperatorId in a few more places.Alexis Hunt2009-11-281-1/+8
| | | | llvm-svn: 90030
* Implement the rules in C++ [basic.link] and C99 6.2.2 for computingDouglas Gregor2009-11-251-2/+2
| | | | | | | | | | | 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. llvm-svn: 89891
* Implement support for default template arguments of function templates.Douglas Gregor2009-11-251-1/+60
| | | | llvm-svn: 89874
* Diagnose ill-formed uses of default template arguments inDouglas Gregor2009-11-251-4/+84
| | | | | | | | | | | 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. llvm-svn: 89872
* Don't crash when we re-use a template specialization node for an explicit ↵Douglas Gregor2009-11-251-5/+9
| | | | | | instantiation. lib/Support/CommandLine.cpp is our test case llvm-svn: 89845
* Fix some major problems dealing with dependently-qualified names in implicitJohn McCall2009-11-241-4/+11
| | | | | | member-reference contexts. Fixes some clang-on-clang asserts. llvm-svn: 89796
* Rip out TemplateIdRefExpr and make UnresolvedLookupExpr and John McCall2009-11-241-94/+272
| | | | | | | | | | | | 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. llvm-svn: 89785
* Set the template specialization kind before instantiating the function ↵Anders Carlsson2009-11-241-2/+2
| | | | | | definition so that the function will have the right linkage. llvm-svn: 89740
* Tolerate extraneous "template<>" headers better, downgrading theDouglas Gregor2009-11-231-4/+16
| | | | | | | | | | 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. llvm-svn: 89651
* Encapsulate "an array of TemplateArgumentLocs and two angle bracket ↵John McCall2009-11-231-73/+42
| | | | | | | | | | locations" into a new class. Use it pervasively throughout Sema. My fingers hurt. llvm-svn: 89638
* Cope with extraneous "template" keyword when providing an out-of-lineDouglas Gregor2009-11-201-3/+4
| | | | | | definition of a member template (or a member thereof). Fixes PR5566. llvm-svn: 89512
* Draw a brighter line between "unresolved" expressions, where we have done theJohn McCall2009-11-191-1/+1
| | | | | | | | 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. llvm-svn: 89402
* Overhaul previous-declaration and overload checking to work on lookup resultsJohn McCall2009-11-181-15/+26
| | | | | | | rather than NamedDecl*. This is a major step towards eliminating OverloadedFunctionDecl. llvm-svn: 89263
* Split LookupResult into its own header.John McCall2009-11-181-1/+2
| | | | llvm-svn: 89199
* Incremental progress on using declarations. Split UnresolvedUsingDecl intoJohn McCall2009-11-181-0/+4
| | | | | | | | | | 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. llvm-svn: 89184
* Require the object type of a member access expression ("." or "->") toDouglas Gregor2009-11-171-6/+6
| | | | | | be complete. llvm-svn: 89042
* Carry lookup configuration throughout lookup on the LookupResult. GiveJohn McCall2009-11-171-22/+18
| | | | | | | | | | | | | 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. llvm-svn: 89027
* Recognize (and check) pointer-to-member template arguments that areDouglas Gregor2009-11-121-27/+34
| | | | | | | | | 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. llvm-svn: 87010
* When comparing template parameter lists, distinguish between three cases:Douglas Gregor2009-11-121-13/+23
| | | | | | | | | | | | | | | | | | | - 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. llvm-svn: 86992
* Improve recovery in a wonky case where one tries to specialize aDouglas Gregor2009-11-121-2/+11
| | | | | | | | | | 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. llvm-svn: 86913
* Template argument deduction for template template parameters. ThisDouglas Gregor2009-11-111-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 :( llvm-svn: 86893
* Improve diagnostics when a default template argument does not matchDouglas Gregor2009-11-111-59/+73
| | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 86884
* Move handling of template parameter packs out of theDouglas Gregor2009-11-111-26/+22
| | | | | | | | | | 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. llvm-svn: 86868
* Refactoring of template-argument checking code to reduce nesting,Douglas Gregor2009-11-111-194/+208
| | | | | | increase sanity. No intended functionality change. llvm-svn: 86866
OpenPOWER on IntegriCloud