summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/TreeTransform.h
Commit message (Collapse)AuthorAgeFilesLines
* Parsing/AST support for Structured Exception HandlingJohn Wiegley2011-04-281-0/+72
| | | | | | | | Patch authored by Sohail Somani. Provide parsing and AST support for Windows structured exception handling. llvm-svn: 130366
* Implementation of Embarcadero array type traitsJohn Wiegley2011-04-281-0/+41
| | | | | | | | | | Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
* fix PR9474, a crash with -fshort-enum and C++ templates: when instantiatingChris Lattner2011-04-251-2/+1
| | | | | | | the enum decl, we need to use an integer type the same size as the enumerator, which may not be the promoted type with packed enums. llvm-svn: 130148
* t/clang/expr-traitsJohn Wiegley2011-04-251-0/+29
| | | | | | | | | Patch authored by David Abrahams. These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for parsing code that employs certain features of the Embarcadero C++ compiler. llvm-svn: 130122
* Fix crashing rdar://9122854 & http://llvm.org/PR9461.Argyrios Kyrtzidis2011-04-221-1/+3
| | | | llvm-svn: 129967
* Support for C++11 (non-template) alias declarations.Richard Smith2011-04-151-5/+6
| | | | llvm-svn: 129567
* C1X: implement generic selectionsPeter Collingbourne2011-04-151-0/+52
| | | | | | | As an extension, generic selection support has been added for all supported languages. The syntax is the same as for C1X. llvm-svn: 129554
* When we transform a C++ exception declaration (e.g., for templateDouglas Gregor2011-04-141-2/+5
| | | | | | | | instantiation), be sure to add the transformed declaration into the current DeclContext. Also, remove the -Wuninitialized hack that works around this bug. Fixes <rdar://problem/9200676>. llvm-svn: 129544
* Add support for C++0x's range-based for loops, as specified by the C++11 ↵Richard Smith2011-04-141-0/+77
| | | | | | draft standard (N3291). llvm-svn: 129541
* Use ExprResult& instead of Expr *& in SemaJohn Wiegley2011-04-081-27/+29
| | | | | | | | | | | | | | | | | | | | | | | | | This patch authored by Eric Niebler. Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr pointers as in/out parameters (Expr *&). This is especially true for the routines that apply implicit conversions to nodes in-place. This design is workable only as long as those conversions cannot fail. If they are allowed to fail, they need a way to report their failures. The typical way of doing this in clang is to use an ExprResult, which has an extra bit to signal a valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema interface. We suggest changing the Expr *& parameters in the Sema interface to ExprResult &. This increases interface consistency and maintainability. This interface change is important for work supporting MS-style C++ properties. For reasons explained here <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>, seemingly trivial operations like rvalue/lvalue conversions that formerly could not fail now can. (The reason is that given the semantics of the feature, getter/setter method lookup cannot happen until the point of use, at which point it may be found that the method does not exist, or it may have the wrong type, or overload resolution may fail, or it may be inaccessible.) llvm-svn: 129143
* Fix an error in TreeTransform where we failed to copy the TemplateName'sChandler Carruth2011-04-011-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | location into a TemplateSpecializationTypeLoc. These were found using a hand-written program to inspect every source location in TemplateSpecializationTypeLocs and Valgrind. I don't know of any way to test them in Clang's existing test suite sadly. Example code that triggers the ElaboratedType case: template <typename T> struct X1 { template <typename U> struct X1_1 { int x; }; }; template <typename T, typename U> struct X2 { typename X1<T>::template X1_1<U> B; }; X2<char, int> x2; The other fix was simply spotted by inspection. I audited all constructions of [Dependent]TemplateSpecializationTypeLocs in TreeTransform.h, and the rest set the TemplateNameLoc properly. llvm-svn: 128702
* Forgotten part of previous commit.Abramo Bagnara2011-03-121-4/+4
| | | | llvm-svn: 127536
* Renamed OffsetOfNode::getRange to getSourceRange for uniformity.Abramo Bagnara2011-03-121-2/+2
| | | | llvm-svn: 127534
* Add support for the OpenCL vec_step operator, by generalising andPeter Collingbourne2011-03-111-17/+22
| | | | | | | extending the existing support for sizeof and alignof. Original patch by Guy Benyei. llvm-svn: 127475
* Fixed source range for all DeclaratorDecl's.Abramo Bagnara2011-03-081-9/+14
| | | | llvm-svn: 127225
* When rebuilding a dependent template specialization type to anotherDouglas Gregor2011-03-071-3/+4
| | | | | | | dependent template specialization type, make sure to set the keyword location. Fixes some valgrind issues introduced in r127150. llvm-svn: 127159
* When transforming a dependent template specialization type, make sureDouglas Gregor2011-03-071-5/+18
| | | | | | | | | to set the source-location information for the template arguments to the *transformed* source-location information, not the original source-location information. Fixes <rdar://problem/8986308> (a libc++ SFINAE issue) and the Boost.Polygon failure. llvm-svn: 127150
* Fix copy-and-paste typo in the transformation of Microsoft __uuidof ↵Douglas Gregor2011-03-061-1/+1
| | | | | | expressions, from Eric Niebler via John Wiegley llvm-svn: 127123
* When transforming a substituted template type parameter, try toDouglas Gregor2011-03-051-1/+22
| | | | | | | | | | | | | | | transform the type that replaces the template type parameter. In the vast majority of cases, there's nothing to do, because most template type parameters are replaced with something non-dependent that doesn't need further transformation. However, when we're dealing with the default template arguments of template template parameters, we might end up replacing a template parameter (of the template template parameter) with a template parameter of the enclosing template. This addresses part of PR9016, but not within function templates. That's a separate issue. llvm-svn: 127091
* Improved MemberPointerType source locations.Abramo Bagnara2011-03-051-9/+21
| | | | llvm-svn: 127085
* When constructing source-location information for aDouglas Gregor2011-03-041-6/+8
| | | | | | | | | | DependentTemplateSpecializationType during tree transformation, retain the NestedNameSpecifierLoc as it was used to translate the template name, rather than reconstructing it from the template name. Fixes PR9401. llvm-svn: 127015
* When we use the default template arguments of a template templateDouglas Gregor2011-03-031-3/+3
| | | | | | | | | | | | | parameter, save the instantiated default template arguments along with the explicitly-specified template argument list. That way, we prefer the default template template arguments corresponding to the template template parameter rather than those of its template template argument. This addresses the likely direction of C++ core issue 150, and fixes PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of EDG and GCC. llvm-svn: 126920
* Eliminate an unnecessary TemporaryBase object from TreeTransformDouglas Gregor2011-03-021-2/+0
| | | | llvm-svn: 126857
* Kill off theDouglas Gregor2011-03-021-65/+0
| | | | | | | | | | TreeTransform::TransformDependentTemplateSpecializationType() with poor source-location information handling. All of the CXXScopeSpec::MakeTrivial() and NestedNameSpecifierLocBuilder::MakeTrivial() callers actually make sense now. llvm-svn: 126856
* Eliminate TreeTransform::RebuildNestedNameSpecifier(), all four ofDouglas Gregor2011-03-021-96/+0
| | | | | | them, which are no longer used. llvm-svn: 126855
* Eliminate an unnecessary use of CXXScopeSpec::MakeTrivial. We have proper ↵Douglas Gregor2011-03-021-3/+1
| | | | | | nested-name-specifier source-location information in DependentTemplateSpecializationTypeLocs now llvm-svn: 126854
* Kill off TreeTransform::TransformNestedNameSpecifier() in favor of theDouglas Gregor2011-03-021-111/+1
| | | | | | | | source-location-preserving TreeTransform::TranformNestedNameSpecifierLoc(). No functionality change: the victim had no callers (that themselves had callers) anyway. llvm-svn: 126853
* Kill off the TreeTransform::TransformTemplateName overload that hasDouglas Gregor2011-03-021-119/+9
| | | | | | poor source-location information. llvm-svn: 126852
* Kill off one of the TreeTransform::TransformTypeInObjectScope()Douglas Gregor2011-03-021-91/+65
| | | | | | overloads (the one with the poor source-location information). llvm-svn: 126851
* Start migrating TreeTransform's TransformTemplateName over to versionDouglas Gregor2011-03-021-74/+156
| | | | | | | that preserve source-location information. This commit adds more redundancy than it removes; WIP. llvm-svn: 126849
* Push nested-name-specifier source location information into templateDouglas Gregor2011-03-021-8/+27
| | | | | | | | | | | | 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
* When we're substituting into a parameter-type-list nested inside the patternDouglas Gregor2011-03-021-7/+15
| | | | | | | | of an expansion, and we have a paramameter that is not a parameter pack, don't suppress substitution of parameter packs within this context. llvm-svn: 126819
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-011-11/+112
| | | | | | | | 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
* Reinstate the introduction of source-location information forDouglas Gregor2011-03-011-13/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r126748, my second attempt at nested-name-specifier sourceDouglas Gregor2011-03-011-21/+13
| | | | | | location information for elaborated types. *sigh* llvm-svn: 126753
* Reinstate r126737, extending the generation of type-source locationDouglas Gregor2011-03-011-13/+21
| | | | | | | | | | | | | | | | | | | | | | | | | 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-21/+13
| | | | | | buildbot breakage. llvm-svn: 126746
* Push nested-name-specifier source location information into elaboratedDouglas Gregor2011-03-011-13/+21
| | | | | | | | | | | | | | | | | | | 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
* Push nested-name-specifier source location information intoDouglas Gregor2011-03-011-18/+19
| | | | | | | | | | | | 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
* Teach Sema::CheckTypenameType to use nested-name-specifiers withDouglas Gregor2011-02-281-2/+3
| | | | | | | | source-location information. We don't actually preserve this information in any of the resulting TypeLocs (yet), so it doesn't matter. llvm-svn: 126693
* Push nested-name-specifier location information into DeclRefExpr andDouglas Gregor2011-02-281-29/+23
| | | | | | MemberExpr, the last of the expressions with qualifiers! llvm-svn: 126688
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-281-17/+13
| | | | | | | | | | | | | 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-281-38/+22
| | | | | | | | 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-281-13/+95
| | | | | | | | 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
* When we encounter a dependent template name within aDouglas Gregor2011-02-281-0/+3
| | | | | | | | | | | | nested-name-specifier, e.g., T::template apply<U>:: represent the dependent template name specialization as a DependentTemplateSpecializationType, rather than a TemplateSpecializationType with a dependent TemplateName. llvm-svn: 126593
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-251-12/+9
| | | | | | | DependentScopeDeclRefExpr. Plus, give NestedNameSpecifierLoc == and != operators, since we're going to need 'em elsewhere. llvm-svn: 126508
* Push nested-name-specifier source-location information intoDouglas Gregor2011-02-251-30/+18
| | | | | | | | pseudo-destructor expressions. Also, clean up some template-instantiation and type-checking issues with pseudo-destructors. llvm-svn: 126498
* Use NestedNameSpecifierLoc within out-of-line variables, function, andDouglas Gregor2011-02-251-2/+174
| | | | | | | tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
* Retain complete source-location information for C++Douglas Gregor2011-02-241-12/+12
| | | | | | | | | | | | nested-name-specifiers throughout the parser, and provide a new class (NestedNameSpecifierLoc) that contains a nested-name-specifier along with its type-source information. Right now, this information is completely useless, because we don't actually store the source-location information anywhere in the AST. Call this Step 1/N. llvm-svn: 126391
* Teach NestedNameSpecifier to keep track of namespace aliases the sameDouglas Gregor2011-02-241-0/+31
| | | | | | | | way it keeps track of namespaces. Previously, we would map from the namespace alias to its underlying namespace when building a nested-name-specifier, losing source information in the process. llvm-svn: 126358
OpenPOWER on IntegriCloud