summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaTemplate/explicit-specialization-member.cpp
Commit message (Collapse)AuthorAgeFilesLines
* CWG issue 727: Fix numerous bugs in support for class-scope explicitRichard Smith2019-05-031-6/+20
| | | | | | specializations for variable templates. llvm-svn: 359947
* PR41607: Don't forget to substitute outer template arguments into aRichard Smith2019-04-261-0/+17
| | | | | | class-scope explicit specialization of a class template. llvm-svn: 359266
* [Sema] Fix an assert-on-invalid by avoiding function template specialisationAlex Lorenz2017-10-271-8/+4
| | | | | | | | | | | | | deduction for invalid functions The fabricated template parameters cause an assertion because their depth is invalid. rdar://34109988 Differential Revision: https://reviews.llvm.org/D37341 llvm-svn: 316778
* Don't mark a member as a member specialization until we know we're keeping ↵Richard Smith2017-05-091-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | the specialization. This improves our behavior in a few ways: * We now guarantee that if a member is marked as being a member specialization, there will actually be a member specialization declaration somewhere on its redeclaration chain. This fixes a crash in modules builds where we would try to check that there was a visible declaration of the member specialization and be surprised to not find any declaration of it at all. * We don't set the source location of the in-class declaration of the member specialization to the out-of-line declaration's location until we have actually finished merging them. This fixes some very silly looking diagnostics, where we'd point a "previous declaration is here" note at the same declaration we're complaining about. Ideally we wouldn't mess with the prior declaration's location at all, but too much code assumes that the first declaration of an entity is a reasonable thing to use as an indication of where it was declared, and that's not really true for a member specialization unless we fake it like this. llvm-svn: 302596
* Speculatively revert r295118 to see if it's what's causing the modules ↵Richard Smith2017-02-151-11/+0
| | | | | | selfhost buildbots to fail. llvm-svn: 295146
* Do not implicitly instantiate the definition of a class template specializationRichard Smith2017-02-141-0/+11
| | | | | | | | | | | | | | | that has been explicitly specialized! We assume in various places that we can tell the template specialization kind of a class type by looking at the declaration produced by TagType::getDecl. That was previously not quite true: for an explicit specialization, we could have first seen a template-id denoting the specialization (with a use that does not trigger an implicit instantiation of the defintiion) and then seen the first explicit specialization declaration. TagType::getDecl would previously return an arbitrary declaration when called on a not-yet-defined class; it now consistently returns the most recent declaration in that case. llvm-svn: 295118
* Fix crash-on-invalid and name lookup when recovering from ~X::X() typo.Richard Smith2015-01-151-1/+1
| | | | llvm-svn: 226067
* PR19340: If we see a declaration of a member of an unspecialized class templateRichard Smith2014-04-171-4/+14
| | | | | | | that looks like it might be an explicit specialization, don't recover as an explicit specialization (bypassing the check that would reject that). llvm-svn: 206444
* PR18246: When performing template argument deduction to decide which templateRichard Smith2013-12-141-0/+19
| | | | | | | | | | is specialized by an explicit specialization, start from the first declaration in case we've got a member of a class template (redeclarations might not number the template parameters the same way). Our recover here is still far from ideal. llvm-svn: 197305
* Add regression test for PR12331.Richard Smith2013-07-021-0/+9
| | | | llvm-svn: 185453
* Instantiate class member template partial specialization declarationsDouglas Gregor2010-11-101-4/+2
| | | | | | | | | in the order they occur within the class template, delaying out-of-line member template partial specializations until after the class has been fully instantiated. This fixes a regression introduced by r118454 (itself a fix for PR8001). llvm-svn: 118704
* Fix some redundant errors by changing CXXScopeSpec::isSet calls intoJeffrey Yasskin2010-04-071-1/+1
| | | | | | isNotEmpty calls. llvm-svn: 100722
* Fix an assertion-on-error during tentative constructor parsing byJohn McCall2010-02-261-1/+1
| | | | | | | | | | propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
* Do not try to instantiate invalid declarations. It's a recipe forDouglas Gregor2010-02-161-0/+12
| | | | | | disaster. Fixes PR6161. llvm-svn: 96371
* Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar2009-12-151-1/+1
| | | | | | | | | - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
* 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
OpenPOWER on IntegriCloud