summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaTemplate
Commit message (Collapse)AuthorAgeFilesLines
* Improve the internal representation and semantic analysis of friendDouglas Gregor2009-10-131-0/+18
| | | | | | | | | | | | | | | function templates. This commit ensures that friend function templates are constructed as FunctionTemplateDecls rather than partial FunctionDecls (as they previously were). It then implements template instantiation for friend function templates, injecting the friend function template only when no previous declaration exists at the time of instantiation. Oh, and make sure that explicit specialization declarations are not friends. llvm-svn: 83970
* Diagnose the declaration of explicit specializations after an implicitDouglas Gregor2009-10-121-2/+4
| | | | | | | instantiation has already been required. To do so, keep track of the point of instantiation for anything that can be instantiated. llvm-svn: 83890
* When declaring a friend class template, we may end up finding anDouglas Gregor2009-10-091-0/+16
| | | | | | | | injected-class-name (e.g., when we're referring to other specializations of the current class template). Make sure that we see the template rather than the injected-class-name. Fixes PR4768. llvm-svn: 83672
* Make sure to set the template specialization kind of an explicitDouglas Gregor2009-10-081-2/+1
| | | | | | | template instantiation of a member function of a class template. FIXME -= 2; llvm-svn: 83520
* Keep track of whether a member function instantiated from a memberDouglas Gregor2009-10-071-2/+2
| | | | | | | | | function of a class template was implicitly instantiated, explicitly instantiated (declaration or definition), or explicitly specialized. The same MemberSpecializationInfo structure will be used for static data members and member classes as well. llvm-svn: 83509
* Type checking for specializations of member functions of classDouglas Gregor2009-10-071-2/+3
| | | | | | | | templates. Previously, these weren't handled as specializations at all. The AST for representing these as specializations is still a work in progress. llvm-svn: 83498
* Refactor checking of the scope of explicit template specializationDouglas Gregor2009-10-072-4/+4
| | | | | | | | | declarations and explicit template instantiations, improving diagnostics and making the code usable for function template specializations (as well as class template specializations and partial specializations). llvm-svn: 83436
* Make sure to free the explicit template arguments provided for anDouglas Gregor2009-10-011-0/+4
| | | | | | | explicit instantiation. Also, tighten up reference-count checking to help catch these issues earlier. Fixes PR5069. llvm-svn: 83225
* When overload resolution fails for an overloaded operator, show theDouglas Gregor2009-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | overload candidates (but not the built-in ones). We still rely on the underlying built-in semantic analysis to produce the initial diagnostic, then print the candidates following that diagnostic. One side advantage of this approach is that we can perform more validation of C++'s operator overloading with built-in candidates vs. the semantic analysis for those built-in operators: when there are no viable candidates, we know to expect an error from the built-in operator handling code. Otherwise, we are not modeling the built-in semantics properly within operator overloading. This is checked as: assert(Result.isInvalid() && "C++ binary operator overloading is missing candidates!"); if (Result.isInvalid()) PrintOverloadCandidates(CandidateSet, /*OnlyViable=*/false); The assert() catches cases where we're wrong in a +Asserts build. The "if" makes sure that, if this happens in a production clang (-Asserts), we still build the proper built-in operator and continue on our merry way. This is effectively what happened before this change, but we've added the assert() to catch more flies. llvm-svn: 83175
* Slightly improve the semantics of extern templates for member functions of ↵Douglas Gregor2009-09-291-0/+26
| | | | | | class templates llvm-svn: 83063
* Parse a C++ scope specifier followed by a "typename" annotation token as a ↵Douglas Gregor2009-09-281-0/+9
| | | | | | type name within the declaration specifiers. Fixes PR5061. llvm-svn: 82974
* Improve handling of friend function templates somewhatDouglas Gregor2009-09-281-1/+14
| | | | llvm-svn: 82950
* Simplify the handling of non-dependent friend class templateDouglas Gregor2009-09-261-0/+4
| | | | | | | | | | | | specializations such as: friend class std::vector<int>; by using the same code path as explicit specializations, customized to reference an existing ClassTemplateSpecializationDecl (or build a new "undeclared" one). llvm-svn: 82875
* Rework the Parse-Sema interaction for friends to better support friendDouglas Gregor2009-09-261-0/+17
| | | | | | | | | class templates. We now treat friend class templates much more like normal class templates, except that they still get special name lookup rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in <iostream>. llvm-svn: 82848
* Use explicitly-specified template argument lists to help namingDouglas Gregor2009-09-251-0/+10
| | | | | | explicit template specializations, when available. llvm-svn: 82824
* Declarators can now properly represent template-ids, e.g., forDouglas Gregor2009-09-251-0/+14
| | | | | | | | | | | template void f<int>(int); ~~~~~~ Previously, we silently dropped the template arguments. With this change, we now use the template arguments (when available) as the explicitly-specified template arguments used to aid template argument deduction for explicit template instantiations. llvm-svn: 82806
* WIP implementation of explicit instantiation of function templates,Douglas Gregor2009-09-251-0/+57
| | | | | | | | member functions of class template specializations, and static data members. The mechanics are (mostly) present, but the semantic analysis is very weak. llvm-svn: 82789
* Fix checking for a null pointer constant when the expression itself isDouglas Gregor2009-09-251-0/+29
| | | | | | | | | | | | value-dependent. Audit (and fixed) all calls to Expr::isNullPointerConstant() to provide the correct behavior with value-dependent expressions. Fixes PR5041 and a crash in libstdc++ <locale>. In the same vein, properly compute value- and type-dependence for ChooseExpr. Fixes PR4996. llvm-svn: 82748
* When entering the scope of a declarator, make sure that the scope isDouglas Gregor2009-09-241-0/+11
| | | | | | | | complete (or, possibly causing template instantiation). Test this via some explicit specializations of member functions. llvm-svn: 82732
* WIP implementation of explicit function template specialization. ThisDouglas Gregor2009-09-241-0/+25
| | | | | | | | | | | | | | | | | | | | | first implementation recognizes when a function declaration is an explicit function template specialization (based on the presence of a template<> header), performs template argument deduction + ambiguity resolution to determine which template is being specialized, and hooks There are many caveats here: - We completely and totally drop any explicitly-specified template arguments on the floor - We don't diagnose any of the extra semantic things that we should diagnose. - I haven't looked to see that we're getting the right linkage for explicit specializations On a happy note, this silences a bunch of errors that show up in libstdc++'s <iostream>, although Clang still can't get through the entire header. llvm-svn: 82728
* Merge uninstantiated default arguments more carefully, and try not toDouglas Gregor2009-09-171-0/+6
| | | | | | | complain about specializations of member functions that are not definitions. Fixes PR4995. llvm-svn: 82159
* Teach Sema::FindInstantiatedDecl to find instantiated RecordDecls evenDouglas Gregor2009-09-161-0/+10
| | | | | | | | | | when we are not instantiating the corresponding "current instantiation." This happens, e.g., when we are instantiating a declaration reference that refers into the "current instantiation" but occurs in a default function argument. The libstdc++ vector default constructor now instantiates properly. llvm-svn: 82069
* Commit test case from PR4655, which tests the canonical-types fix in r81913Douglas Gregor2009-09-151-0/+5
| | | | llvm-svn: 81916
* When printing an overload candidate that is a function template specialization,Douglas Gregor2009-09-151-0/+9
| | | | | | | | | | point at the template and print out its template arguments, e.g., ambiguous-ovl-print.cpp:5:8: note: candidate function template specialization [with T = int] void f(T*, long); llvm-svn: 81907
* Add an assertion and a test case, in a fruitless attempt to track down an ↵Douglas Gregor2009-09-151-0/+20
| | | | | | existing bug llvm-svn: 81885
* Implement partial ordering of class template partial specializations Douglas Gregor2009-09-152-2/+44
| | | | | | (C++ [temp.class.order]). llvm-svn: 81866
* Implement partial ordering of function templates when calling aDouglas Gregor2009-09-141-1/+10
| | | | | | conversion function. llvm-svn: 81807
* Implement partial ordering of function template specializations Douglas Gregor2009-09-141-0/+86
| | | | | | (C++ [temp.func.order]). llvm-svn: 81777
* Fix a bug in getFriendObjectKind where we would clear out all mask bits ↵Anders Carlsson2009-09-131-0/+10
| | | | | | except IDNS_TagFriend and IDNS_OrdinaryFriend but then check for IDNS_Tag and IDNS_Ordinary. llvm-svn: 81730
* Slight improvement for extern templates, so that an explicitDouglas Gregor2009-09-111-3/+14
| | | | | | | | | instantiation definition can follow an explicit instantiation declaration. This is as far as I want to go with extern templates now, but they will still need quite a bit more work to get all of the C++0x semantics right. llvm-svn: 81573
* Improve testing for extern temp templates, slightly. We are (properly) ↵Douglas Gregor2009-09-111-6/+16
| | | | | | suppressing the implicit instantiation of members of extern templates llvm-svn: 81567
* Cleanup and test C++ default arguments. Improvements include:Douglas Gregor2009-09-111-0/+21
| | | | | | | | | | | - Diagnose attempts to add default arguments to templates (or member functions of templates) after the initial declaration (DR217). - Improve diagnostics when a default argument is redefined. Now, the note will always point at the place where the default argument was previously defined, rather than pointing to the most recent declaration of the function. llvm-svn: 81548
* Track a class template specialization's point of instantiation separatelyJohn McCall2009-09-111-3/+2
| | | | | | | | | | from its location. Initialize appropriately. When implicitly creating a declaration of a class template specialization after encountering the first reference to it, use the pattern class's location instead of the location of the first reference. llvm-svn: 81515
* When re-entering a template scope, we may be entering a class templateDouglas Gregor2009-09-101-0/+10
| | | | | | | partial specialization rather than a subclass of TemplateDecl. Fixes a crash in libstdc++ 4.2's <map>. llvm-svn: 81407
* Initial stab at implement dependent member references to memberDouglas Gregor2009-09-091-0/+30
| | | | | | | | | | | | | templates, e.g., x.template get<T> We can now parse these, represent them within an UnresolvedMemberExpr expression, then instantiate that expression node in simple cases. This allows us to stumble through parsing LLVM's Casting.h. llvm-svn: 81300
* Reapply 81096, now with a fix. Spot the bug:Anders Carlsson2009-09-061-1/+4
| | | | | | | | | for (unsigned i = numargs; i < NumArgs; ++i) Args[0] = 0; ;) llvm-svn: 81123
* Revert "Initialize default CXXConstructExpr arguments to 0. Fixes a crash whenDaniel Dunbar2009-09-061-4/+1
| | | | | | | destroying the CXXConstructExpr.", this is causing test failures across the board. llvm-svn: 81100
* Initialize default CXXConstructExpr arguments to 0. Fixes a crash when ↵Anders Carlsson2009-09-051-1/+4
| | | | | | destroying the CXXConstructExpr. llvm-svn: 81096
* Report errors for member functions correctly.Anders Carlsson2009-09-051-0/+7
| | | | llvm-svn: 81063
* Use a separate diagnostic for default function argument expressions.Anders Carlsson2009-09-051-5/+5
| | | | llvm-svn: 81062
* Don't generate any code for an explicit call to a trivial destructor. Douglas Gregor2009-09-041-4/+10
| | | | | | | | | | | Now that parsing, semantic analysis, and (I think) code generation of pseudo-destructor expressions and explicit destructor calls works, update the example-dynarray.cpp test to destroy the objects it allocates and update the test to actually compile + link. The code seems correct, but the Clang-compiled version dies with a malloc error. Time to debug! llvm-svn: 81025
* Implement AST, semantics, and CodeGen for C++ pseudo-destructorDouglas Gregor2009-09-041-0/+16
| | | | | | | | | | | | | expressions, e.g., p->~T() when p is a pointer to a scalar type. We don't currently diagnose errors when pseudo-destructor expressions are used in any way other than by forming a call. llvm-svn: 81009
* Parse extern templates, pass that information all the way to Sema,Douglas Gregor2009-09-041-0/+20
| | | | | | then drop it on the floor. llvm-svn: 80989
* Implement tree transformations for DeclarationNames. Among otherDouglas Gregor2009-09-031-0/+13
| | | | | | | | | | | things, this means that we can properly cope with member access expressions such as t->operator T() where T is a template parameter (or other dependent type). llvm-svn: 80957
* Improve template instantiation for member access expressions thatDouglas Gregor2009-09-031-4/+4
| | | | | | | | | involve qualified names, e.g., x->Base::f. We now maintain enough information in the AST to compare the results of the name lookup of "Base" in the scope of the postfix-expression (determined at template definition time) and in the type of the object expression. llvm-svn: 80953
* Add a wicked little test-case that illustrates what we have to dealDouglas Gregor2009-09-021-0/+48
| | | | | | | | with to properly support member access expressions in templates. This test is XFAIL'd, because we get it completely wrong, but I've made the minimal changes to the representation to at least avoid a crash. llvm-svn: 80856
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | x->Base::f We no longer try to "enter" the context of the type that "x" points to. Instead, we drag that object type through the parser and pass it into the Sema routines that need to know how to perform lookup within member access expressions. We now implement most of the crazy name lookup rules in C++ [basic.lookup.classref] for non-templated code, including performing lookup both in the context of the type referred to by the member access and in the scope of the member access itself and then detecting ambiguities when the two lookups collide (p1 and p4; p3 and p7 are still TODO). This change also corrects our handling of name lookup within template arguments of template-ids inside the nested-name-specifier (p6; we used to look into the scope of the object expression for them) and fixes PR4703. I have disabled some tests that involve member access expressions where the object expression has dependent type, because we don't yet have the ability to describe dependent nested-name-specifiers starting with an identifier. llvm-svn: 80843
* Add a few more typename-specifier tests that involve simple-template-ids in ↵Douglas Gregor2009-09-021-0/+14
| | | | | | the nested-name-specifier llvm-svn: 80784
* When parsing typename specifiers (with either the identifier orDouglas Gregor2009-09-021-0/+56
| | | | | | | | | | | | simple-template-id form), check whether the scope specifier is computable as a declaration context rather than checking whether it is dependent, so that we properly cope with members of the current instantiation. Improve testing for typename specifiers that terminate in a simpe-template-id. llvm-svn: 80783
* Implement proper substitution for OverloadedFunctionDecls, but substituting ↵Douglas Gregor2009-09-011-0/+18
| | | | | | each of the functions in the overload set llvm-svn: 80692
OpenPOWER on IntegriCloud