summaryrefslogtreecommitdiff
path: root/test/Index/annotate-nested-name-specifier.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Print nested name specifiers for typedefs and type aliasesAlex Lorenz2017-03-101-19/+19
| | | | | | | | | | | | | Printing typedefs or type aliases using clang_getTypeSpelling() is missing the namespace they are defined in. This is in contrast to other types that always yield the full typename including namespaces. Patch by Michael Reiher! Differential Revision: https://reviews.llvm.org/D29944 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297465 91177308-0d34-0410-b5e6-96231b3b80d8
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Under this defect resolution, the injected-class-name of a class or class template cannot be used except in very limited circumstances (when declaring a constructor, in a nested-name-specifier, in a base-specifier, or in an elaborated-type-specifier). This is apparently done to make parsing easier, but it's a pain for us since we don't know whether a template-id using the injected-class-name is valid at the point when we annotate it (we don't yet know whether the template-id will become part of an elaborated-type-specifier). As a tentative resolution to a perceived language defect, mem-initializer-ids are added to the list of exceptions here (they generally follow the same rules as base-specifiers). When the reference to the injected-class-name uses the 'typename' or 'template' keywords, we permit it to be used to name a type or template as an extension; other compilers also accept some cases in this area. There are also a couple of corner cases with dependent template names that we do not yet diagnose, but which will also get this treatment. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292518 91177308-0d34-0410-b5e6-96231b3b80d8
* [libclang] Make token annotation of type/storage qualifiers accurate.Argyrios Kyrtzidis2013-01-071-5/+5
| | | | | | | | Previously type/storage qualifiers would not be annotated as the declaration they belonged to. Just use the resulting source range of getRawCursorExtent() which is more correct than what AnnotateTokensWorker::Visit() was adjusting it to. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171774 91177308-0d34-0410-b5e6-96231b3b80d8
* Expose more statement, expression, and declaration kinds in libclang,Douglas Gregor2011-10-051-29/+29
| | | | | | | from Manuel Holtgrewe! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141200 91177308-0d34-0410-b5e6-96231b3b80d8
* Enable -fdelayed-template-parsing by default on Win32.Francois Pichet2011-09-011-1/+1
| | | | | | | I had to force -fno-delayed-template-parsing on some Index tests because delayed template parsing will change the output of some tests. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138942 91177308-0d34-0410-b5e6-96231b3b80d8
* Based on the new information in the AST provided by r130628, writeChandler Carruth2011-05-011-5/+5
| | | | | | | | | | | 3 lines of code and improve a bunch of information in the libclang view of the code. Updates the two tests that exercise this with the new data, checking that each new source location actually points back to the declared template parameter. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130656 91177308-0d34-0410-b5e6-96231b3b80d8
* Use ElaboratedType also for C.Abramo Bagnara2011-03-161-4/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127755 91177308-0d34-0410-b5e6-96231b3b80d8
* Finish updated testDouglas Gregor2011-03-031-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126948 91177308-0d34-0410-b5e6-96231b3b80d8
* Eliminate redundant nested-name-specifiers onDouglas Gregor2011-03-031-2/+2
| | | | | | | TemplateSpecializationTypes, which also fixes PR9388. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126946 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix the source range for a member access expression that includes aDouglas Gregor2011-03-021-1/+16
| | | | | | | | nested-name-specifier and improve the detection of implicit 'this' bases. Fixes <rdar://problem/8750392>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126880 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach libclang how to visit the children of a C++ base-class specifierDouglas Gregor2011-03-021-1/+12
| | | | | | | (i.e., the TypeLoc describing the base class type). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126861 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source location information into templateDouglas Gregor2011-03-021-1/+35
| | | | | | | | | | | | | | template arguments. I believe that this is the last place in the AST where we were storing a source range for a nested-name-specifier rather than a proper nested-name-specifier location structure. (Yay!) There is still a lot of cleanup to do in the TreeTransform, which doesn't take advantage of nested-name-specifiers with source-location information everywhere it could. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126844 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-021-9/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | template specialization types. This also required some parser tweaks, since we were losing track of the nested-name-specifier's source location information in several places in the parser. Other notable changes this required: - Sema::ActOnTagTemplateIdType now type-checks and forms the appropriate type nodes (+ source-location information) for an elaborated-type-specifier ending in a template-id. Previously, we used a combination of ActOnTemplateIdType and ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped around a DependentTemplateSpecializationType, which duplicated the keyword ("class", "struct", etc.) and nested-name-specifier storage. - Sema::ActOnTemplateIdType now gets a nested-name-specifier, which it places into the returned type-source location information. - Sema::ActOnDependentTag now creates types with source-location information. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126808 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-011-1/+45
| | | | | | | | | template specialization types. There are still a few rough edges to clean up with some of the parser actions dropping nested-name-specifiers too early. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126776 91177308-0d34-0410-b5e6-96231b3b80d8
* Reinstate the introduction of source-location information forDouglas Gregor2011-03-011-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | nested-name-speciciers within elaborated type names, e.g., enum clang::NestedNameSpecifier::SpecifierKind Fixes in this iteration include: (1) Compute the type-source range properly for a dependent template specialization type that starts with "template template-id ::", as in a member access expression dep->template f<T>::f() This is a latent bug I triggered with this change (because now we're checking the computed source ranges for dependent template specialization types). But the real problem was... (2) Make sure to set the qualifier range on a dependent template specialization type appropriately. This will go away once we push nested-name-specifier locations into dependent template specialization types, but it was the source of the valgrind errors on the buildbots. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126765 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r126748, my second attempt at nested-name-specifier sourceDouglas Gregor2011-03-011-13/+0
| | | | | | | location information for elaborated types. *sigh* git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126753 91177308-0d34-0410-b5e6-96231b3b80d8
* Reinstate r126737, extending the generation of type-source locationDouglas Gregor2011-03-011-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | information for qualifier type names throughout the parser to address several problems. The commit message from r126737: Push nested-name-specifier source location information into elaborated name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind". Aside from the normal changes, this also required some tweaks to the parser. Essentially, when we're looking at a type name (via getTypeName()) specifically for the purpose of creating an annotation token, we pass down the flag that asks for full type-source location information to be stored within the returned type. That way, we retain source-location information involving nested-name-specifiers rather than trying to reconstruct that information later, long after it's been lost in the parser. With this change, test/Index/recursive-cxx-member-calls.cpp is showing much improved results again, since that code has lots of nested-name-specifiers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126748 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r126737, the most recent nested-name-specifier location change, for ↵Douglas Gregor2011-03-011-13/+0
| | | | | | buildbot breakage. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126746 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source location information into elaboratedDouglas Gregor2011-03-011-0/+13
| | | | | | | | | | | | | | | | | | | | | name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind". Aside from the normal changes, this also required some tweaks to the parser. Essentially, when we're looking at a type name (via getTypeName()) specifically for the purpose of creating an annotation token, we pass down the flag that asks for full type-source location information to be stored within the returned type. That way, we retain source-location information involving nested-name-specifiers rather than trying to reconstruct that information later, long after it's been lost in the parser. With this change, test/Index/recursive-cxx-member-calls.cpp is showing much improved results again, since that code has lots of nested-name-specifiers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126737 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source location information intoDouglas Gregor2011-03-011-2/+58
| | | | | | | | | | | | | DependentNameTypeLoc. Teach the recursive AST visitor and libclang how to walk DependentNameTypeLoc nodes. Also, teach libclang about TypedefDecl source ranges, so that we get those. The massive churn in test/Index/recursive-cxx-member-calls.cpp is a good thing: we're annotating a lot more of this test correctly now. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126729 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier location information into DeclRefExpr andDouglas Gregor2011-02-281-2/+52
| | | | | | | MemberExpr, the last of the expressions with qualifiers! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126688 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-281-1/+55
| | | | | | | | | | | | | | | UnresolvedLookupExpr and UnresolvedMemberExpr. Also, improve the computation that checks whether the base of a member expression (either unresolved or dependent-scoped) is implicit. The previous check didn't cover all of the cases we use in our representation, which threw off source-location information for these expressions (which, in turn, caused some breakage in libclang's token annotation). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126681 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source-location information intoDouglas Gregor2011-02-251-1/+29
| | | | | | | | | pseudo-destructor expressions. Also, clean up some template-instantiation and type-checking issues with pseudo-destructors. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126498 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source location information into namespaceDouglas Gregor2011-02-251-1/+14
| | | | | | | aliases. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126496 91177308-0d34-0410-b5e6-96231b3b80d8
* Push nested-name-specifier source location information into using directives.Douglas Gregor2011-02-251-1/+19
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126489 91177308-0d34-0410-b5e6-96231b3b80d8
* Direct testing of source-location information on using declarations, via ↵Douglas Gregor2011-02-251-1/+33
| | | | | | libclang git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126487 91177308-0d34-0410-b5e6-96231b3b80d8
* Use NestedNameSpecifierLoc within out-of-line variables, function, andDouglas Gregor2011-02-251-1/+18
| | | | | | | | tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126470 91177308-0d34-0410-b5e6-96231b3b80d8
* Update UsingDecl, UnresolvedUsingTypenameDecl, andDouglas Gregor2011-02-251-0/+42
UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the extremely-lossy NestedNameSpecifier/SourceRange pair it used to use, improving source-location information. Various infrastructure updates to support NestedNameSpecifierLoc: - AST/PCH (de-)serialization - Recursive AST visitor - libclang traversal (including the first tests of this functionality) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126459 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status