summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
* Completed source ranges fixes for all classes inheriting from TypeDecl.Abramo Bagnara2011-03-061-4/+4
| | | | llvm-svn: 127120
* Fixed TypedefDecl and TemplateTypeParameter source range.Abramo Bagnara2011-03-064-13/+19
| | | | llvm-svn: 127119
* Reinstate r127112, "Propagate new-style exception spec information to ↵Sebastian Redl2011-03-062-10/+7
| | | | | | ExtProtoInfo.", this time with the missing header. llvm-svn: 127118
* Revert r127112, "Propagate new-style exception spec information to ↵NAKAMURA Takumi2011-03-062-7/+10
| | | | | | | | ExtProtoInfo." It seems missing "clang/Basic/ExceptionSpecificationType.h". llvm-svn: 127115
* Propagate new-style exception spec information to ExtProtoInfo.Sebastian Redl2011-03-052-10/+7
| | | | llvm-svn: 127112
* Fixed LabelDecl source range and cleaned creation code.Abramo Bagnara2011-03-051-3/+9
| | | | llvm-svn: 127094
* When determining template instantiation arguments within a functionDouglas Gregor2011-03-051-38/+59
| | | | | | | | | | | template (not a specialization!), use the "injected" function template arguments, which correspond to the template parameters of the function template. This is required when substituting into the default template parameters of template template parameters within a function template. Fixes PR9016. llvm-svn: 127092
* When we're deserializing a template parameter declaration, temporarilyDouglas Gregor2011-03-051-3/+0
| | | | | | | | | | use the translation unit as its declaration context, then deserialize the actual lexical and semantic DeclContexts after the template parameter is complete. This avoids problems when the DeclContext itself (e.g., a class template) is dependent on the template parameter (e.g., for the injected-class-name). llvm-svn: 127056
* Currently we can only remap a file by creating a MemoryBuffer and replacing ↵Argyrios Kyrtzidis2011-03-051-2/+2
| | | | | | | | | the file contents with it. Allow remapping a file by specifying another filename whose contents should be loaded if the original file gets loaded. This allows to override files without having to create & load buffers in advance. llvm-svn: 127052
* Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdTypeDouglas Gregor2011-03-041-0/+4
| | | | | | | | to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
* *Recursively* set the context of a template parameter, so that we alsoDouglas Gregor2011-03-041-17/+15
| | | | | | capture the template parameters of template template parameters. llvm-svn: 127012
* Make sure to put template parameters into their owning template'sDouglas Gregor2011-03-042-2/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclContext once we've created it. This mirrors what we do for function parameters, where the parameters start out with translation-unit context and then are adopted by the appropriate DeclContext when it is created. Also give template parameters public access and make sure that they don't show up for the purposes of name lookup. Fixes PR9400, a regression introduced by r126920, which implemented substitution of default template arguments provided in template template parameters (C++ core issue 150). How on earth could the DeclContext of a template parameter affect the handling of default template arguments? I'm so glad you asked! The link is Sema::getTemplateInstantiationArgs(), which determines the outer template argument lists that correspond to a given declaration. When we're instantiating a default template argument for a template template parameter within the body of a template definition (not it's instantiation, per core issue 150), we weren't getting any outer template arguments because the context of the template template parameter was the translation unit. Now that the context of the template template parameter is its owning template, we get the template arguments from the injected-class-name of the owning template, so substitution works as it should. llvm-svn: 127004
* Fixed source range for ClassTemplateSpecializationDecl.Abramo Bagnara2011-03-041-0/+13
| | | | llvm-svn: 126999
* Move private structs into anonymous namespaces.Benjamin Kramer2011-03-041-17/+17
| | | | llvm-svn: 126997
* Improved TemplateTypeParmDecl end location.Abramo Bagnara2011-03-041-1/+11
| | | | llvm-svn: 126996
* Fixed end location of NonTypeTemplateParamDecl.Abramo Bagnara2011-03-041-1/+4
| | | | llvm-svn: 126994
* Don't consider visibility from template parameter lists if we'reJohn McCall2011-03-041-5/+12
| | | | | | | | | computing for a nested decl with explicit visibility. This is all part of the general philosophy of explicit visibility attributes, where any information that was obviously available at the attribute site should probably be ignored. Fixes PR9371. llvm-svn: 126992
* Make AttributedTypes for GC-qualified types and fix some miscellaneousJohn McCall2011-03-042-9/+16
| | | | | | | bugs with such types. Not sure this is quite how I want the desugaring and a.k.a. logic to go, but it suffices. llvm-svn: 126986
* Fixed source range for LabelDecl.Abramo Bagnara2011-03-031-2/+3
| | | | llvm-svn: 126952
* Eliminate redundant nested-name-specifiers onDouglas Gregor2011-03-031-0/+8
| | | | | | TemplateSpecializationTypes, which also fixes PR9388. llvm-svn: 126946
* Removed left brace location from LinkageSpecDecl.Abramo Bagnara2011-03-031-2/+1
| | | | llvm-svn: 126945
* Fixed end source location for LinkageSpecDecl.Abramo Bagnara2011-03-031-2/+4
| | | | llvm-svn: 126943
* Fixed source range for FileScopeAsmDecl. Others source range fixes will follow.Abramo Bagnara2011-03-031-3/+4
| | | | llvm-svn: 126939
* Add a missing break, from John WiegleyDouglas Gregor2011-03-031-0/+1
| | | | llvm-svn: 126919
* Revert "Add CC_Win64ThisCall and set it in the necessary places."Tilmann Scheller2011-03-023-5/+0
| | | | | | This reverts commit 126863. llvm-svn: 126886
* Fix the source range for a member access expression that includes aDouglas Gregor2011-03-022-37/+60
| | | | | | | nested-name-specifier and improve the detection of implicit 'this' bases. Fixes <rdar://problem/8750392>. llvm-svn: 126880
* Work around a misdesigned GCC warning.John McCall2011-03-021-1/+1
| | | | llvm-svn: 126879
* Add CC_Win64ThisCall and set it in the necessary places.Tilmann Scheller2011-03-023-0/+5
| | | | llvm-svn: 126863
* Push nested-name-specifier source location information into templateDouglas Gregor2011-03-022-10/+19
| | | | | | | | | | | | 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. llvm-svn: 126844
* Provide an attribute, objc_method_family, to allow the inferred familyJohn McCall2011-03-021-0/+16
| | | | | | | | | | of an Objective-C method to be overridden on a case-by-case basis. This is a higher-level tool than ns_returns_retained &c.; it lets users specify that not only does a method have different retain/release semantics, but that it semantically acts differently than one might assume from its name. This in turn is quite useful to static analysis. llvm-svn: 126839
* Move some of the logic about classifying Objective-C methods intoJohn McCall2011-03-021-0/+42
| | | | | | | | conventional categories into Basic and AST. Update the self-init checker to use this logic; CFRefCountChecker is complicated enough that I didn't want to touch it. llvm-svn: 126817
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 126808
* Don't warn about unused values in ternary ?: expressions unless both the LHS ↵Ted Kremenek2011-03-011-5/+7
| | | | | | | | and RHS are "unused" (side-effect free). Patch by Justin Bogner! Fixes PR 8282. llvm-svn: 126779
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-011-0/+20
| | | | | | | | 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. llvm-svn: 126776
* Revert 123553, as sys::fs::unique_file is not finished yet.Dan Gohman2011-03-011-17/+22
| | | | llvm-svn: 126772
* Reinstate the introduction of source-location information forDouglas Gregor2011-03-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 126765
* Implement -mrtd which sets the StdCall calling convention to be the defaultRoman Divacky2011-03-011-4/+11
| | | | | | one. llvm-svn: 126756
* Revert r126748, my second attempt at nested-name-specifier sourceDouglas Gregor2011-03-011-8/+0
| | | | | | location information for elaborated types. *sigh* llvm-svn: 126753
* Reinstate r126737, extending the generation of type-source locationDouglas Gregor2011-03-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 126748
* Revert r126737, the most recent nested-name-specifier location change, for ↵Douglas Gregor2011-03-011-8/+0
| | | | | | buildbot breakage. llvm-svn: 126746
* Push nested-name-specifier source location information into elaboratedDouglas Gregor2011-03-011-0/+8
| | | | | | | | | | | | | | | | | | | 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. llvm-svn: 126737
* Use CharUnits for TypeAlign variable in LayoutWideBitField(). No change inKen Dyck2011-03-011-4/+5
| | | | | | functionality intended. llvm-svn: 126730
* Push nested-name-specifier source location information intoDouglas Gregor2011-03-011-0/+9
| | | | | | | | | | | | 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. llvm-svn: 126729
* Change the return type of GetVirtualPointersSize() to CharUnits. No changeKen Dyck2011-03-011-8/+10
| | | | | | in functionality intended. llvm-svn: 126727
* Refactor the construction of nested-name-specifiers withDouglas Gregor2011-02-281-0/+246
| | | | | | | | | | source-location information into a NestedNameSpecifierLocBuilder class, which lives within the AST library and centralize all knowledge of the format of nested-name-specifier location information here. No functionality change. llvm-svn: 126716
* Push nested-name-specifier location information into DeclRefExpr andDouglas Gregor2011-02-282-29/+21
| | | | | | MemberExpr, the last of the expressions with qualifiers! llvm-svn: 126688
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-281-15/+60
| | | | | | | | | | | | | 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). llvm-svn: 126681
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-282-17/+28
| | | | | | | | CXXDependentScopeMemberExpr, and clean up instantiation of nested-name-specifiers with dependent template specialization types in the process. llvm-svn: 126663
* Eliminate the last remains of TemplateSpecializationTypes withDouglas Gregor2011-02-282-3/+5
| | | | | | | | dependent template names. There is still a lot of redundant code in TreeTransform to cope with TemplateSpecializationTypes, which I'll remove in stages. llvm-svn: 126656
* Unbreak CMake buildDouglas Gregor2011-02-281-0/+1
| | | | llvm-svn: 126653
OpenPOWER on IntegriCloud