summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-022-44/+102
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-014-20/+122
| | | | | | | | 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
* Don't warning about shifting by too many bits in dead code.Ted Kremenek2011-03-011-1/+3
| | | | llvm-svn: 126770
* For C++, enhance -Warray-bounds to recursively analyze array subscript ↵Ted Kremenek2011-03-013-22/+41
| | | | | | accesses in ?: expressions. llvm-svn: 126766
* Reinstate the introduction of source-location information forDouglas Gregor2011-03-017-32/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't wanr about "negative shifts" in code that is unreachable. Fixes PR 5544.Ted Kremenek2011-03-011-1/+3
| | | | llvm-svn: 126762
* Revert r126748, my second attempt at nested-name-specifier sourceDouglas Gregor2011-03-016-63/+32
| | | | | | location information for elaborated types. *sigh* llvm-svn: 126753
* Implement comparison of C++0x scoped enumeration types. Fixes PR9333.Douglas Gregor2011-03-011-0/+7
| | | | llvm-svn: 126752
* When digging into a cv-qualified return type that is a pointer type toDouglas Gregor2011-03-011-1/+1
| | | | | | | | diagnose ignored qualifiers on return types, only assume that there is a pointer chunk if the type is *structurally* a pointer type, not if it's a typedef of a pointer type. Fixes PR9328/<rdar://problem/9055428>. llvm-svn: 126751
* When building a type for a typename specifier, check specifically forDouglas Gregor2011-03-011-40/+34
| | | | | | | | | a dependent template name rather than (indirectly and incorrectly) trying to determine whether we can compute a context for the nested-name-specifier. Fixes a GCC testsuite regression, <rdar://problem/9068589>. llvm-svn: 126749
* Reinstate r126737, extending the generation of type-source locationDouglas Gregor2011-03-016-38/+64
| | | | | | | | | | | | | | | | | | | | | | | | | 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-016-61/+37
| | | | | | buildbot breakage. llvm-svn: 126746
* Move the bool-conversions behind the DiagRuntimeBehavior logic. It'sChandler Carruth2011-03-011-2/+2
| | | | | | | | | possible for these to show up due to metaprogramming both in unevaluated contexts and compile-time dead branches. Those aren't the bugs we're looking for. llvm-svn: 126739
* Push nested-name-specifier source location information into elaboratedDouglas Gregor2011-03-016-37/+61
| | | | | | | | | | | | | | | | | | | 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-014-27/+27
| | | | | | | | | | | | 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
* Refactor the construction of nested-name-specifiers withDouglas Gregor2011-02-281-167/+19
| | | | | | | | | | 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
* Teach Sema::CheckTypenameType to use nested-name-specifiers withDouglas Gregor2011-02-285-39/+38
| | | | | | | | 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-285-51/+33
| | | | | | MemberExpr, the last of the expressions with qualifiers! llvm-svn: 126688
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-285-50/+37
| | | | | | | | | | | | | 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-283-45/+32
| | | | | | | | 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-13/+115
| | | | | | | | 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
* Add a -fcxx-exceptions flag to the frontend, which can be used to enableAnders Carlsson2011-02-282-2/+2
| | | | | | | | | | C++ exceptions, even when exceptions have been turned off using -fno-exceptions. Make the -fobjc-exceptions flag do the same thing, but for Objective-C exceptions. C++ and Objective-C exceptions can also be disabled using -fno-cxx-excptions and -fno-objc-exceptions. llvm-svn: 126630
* When we encounter a dependent template name within aDouglas Gregor2011-02-282-7/+63
| | | | | | | | | | | | 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
* Eliminate a silly little Parse/Sema dance when parsing typenameDouglas Gregor2011-02-271-48/+60
| | | | | | | | | | | | | | | | | | | specifiers such as typename T::template apply<U> Previously, we would turn T::template apply<U> into a TemplateSpecializationType. Then, we'd reprocess that TemplateSpecializationType and turn it into either a TemplateSpecializationType wrapped in an ElaboratedType (when we could resolve "apply" to a template declaration) or a DependentTemplateSpecializationType. We now produce the same ASTs but without generating the intermediate TemplateSpecializationType. The end goal here is to avoid generating TemplateSpecializationTypes with dependent template-names, ever. We're not there yet. llvm-svn: 126589
* Implement delegating constructors partially.Alexis Hunt2011-02-262-8/+68
| | | | | | | | | | | This successfully performs constructor lookup and verifies that a delegating initializer is the only initializer present. This does not perform loop detection in the initialization, but it also doesn't codegen delegating constructors at all, so this won't cause runtime infinite loops yet. llvm-svn: 126552
* Provide a bit saying that a builtin undergoes custom type-checking, thenJohn McCall2011-02-262-19/+50
| | | | | | | don't let calls to such functions go down the normal type-checking path. Test this out with __builtin_classify_type and __builtin_constant_p. llvm-svn: 126539
* Sprinkle optional text of the "unavailable' attributeFariborz Jahanian2011-02-252-19/+28
| | | | | | where ever such attribute causes an error diagnostic. llvm-svn: 126509
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-252-16/+16
| | | | | | | DependentScopeDeclRefExpr. Plus, give NestedNameSpecifierLoc == and != operators, since we're going to need 'em elsewhere. llvm-svn: 126508
* Remove the FIXME I introduced last night, and pull the logic forChandler Carruth2011-02-253-20/+28
| | | | | | | | | | marking selected overloads into the callers. This allows a few callers to skip it altogether (they would have anyways because they weren't interested in successful overloads) or defer until after further checks take place much like the check required for PR9323 to avoid marking unused copy constructors. llvm-svn: 126503
* Print optional message for attr(unavailable) in C++ mode.Fariborz Jahanian2011-02-251-5/+18
| | | | | | // rdar://9046492 llvm-svn: 126499
* Push nested-name-specifier source-location information intoDouglas Gregor2011-02-252-32/+20
| | | | | | | | pseudo-destructor expressions. Also, clean up some template-instantiation and type-checking issues with pseudo-destructors. llvm-svn: 126498
* Push nested-name-specifier source location information into namespaceDouglas Gregor2011-02-252-5/+3
| | | | | | aliases. llvm-svn: 126496
* Push nested-name-specifier source location information into using directives.Douglas Gregor2011-02-252-6/+5
| | | | llvm-svn: 126489
* Switch a few CXXScopeSpec::MakeTrivial() calls over to appropriateDouglas Gregor2011-02-252-7/+9
| | | | | | NestedNameSpecifierLoc handling. llvm-svn: 126486
* Maintain nested-name-specifier source-location information throughDouglas Gregor2011-02-251-23/+17
| | | | | | instantiation of using declarations (all three forms). llvm-svn: 126485
* Rough fix for PR9323 that prevents Clang from marking copy constructorChandler Carruth2011-02-252-3/+12
| | | | | | | | | | | | | | | | declarations as referenced when in fact we're not going to even form a call in the AST. This is significant because we attempt to allow as an extension classes with intentionally private and undefined copy constructors to have temporaries bound to references, and so shouldn't warn about the lack of definition for that copy constructor when the class is internal. Doug, John wasn't really satisfied with the presence of overloading at all. This is a stop-gap and there may be a better solution. If you can give me some hints for how you'd prefer to see this solved, I'll happily switch things over. llvm-svn: 126480
* Formatting, etc.John McCall2011-02-251-17/+17
| | | | llvm-svn: 126475
* Use NestedNameSpecifierLoc within out-of-line variables, function, andDouglas Gregor2011-02-257-63/+243
| | | | | | | tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
* Update UsingDecl, UnresolvedUsingTypenameDecl, andDouglas Gregor2011-02-253-34/+31
| | | | | | | | | | | | | | 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) llvm-svn: 126459
* Don't warn about using PredefinedExprs as format string literals. These ↵Ted Kremenek2011-02-241-1/+7
| | | | | | | | never can be a real security issue. Fixes PR 9314. llvm-svn: 126447
* Retain complete source-location information for C++Douglas Gregor2011-02-248-25/+252
| | | | | | | | | | | | 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
* From Vassil Vassilev:Axel Naumann2011-02-241-1/+6
| | | | | | Add an interface for last resort, unqualified lookup. It can provide results for unqualified lookup when Sema fails to find anything itself. llvm-svn: 126387
* compute the integer width, not the memory width here. We want to know thatChris Lattner2011-02-241-2/+1
| | | | | | | _Bool is 1 bit, not 8. This fixes an assertion on the testcase, which is PR9304 and rdar://9045501. llvm-svn: 126368
* rework processing of unavailable and deprecated attributes to avoid Chris Lattner2011-02-241-25/+19
| | | | | | | unneeded allocation of an empty StringLiteral when these don't have a message. llvm-svn: 126364
* Teach NestedNameSpecifier to keep track of namespace aliases the sameDouglas Gregor2011-02-245-4/+47
| | | | | | | | 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
* Tweak the CXXScopeSpec API a bit, so that we require theDouglas Gregor2011-02-246-52/+28
| | | | | | nested-name-specifier and source range to be set at the same time. llvm-svn: 126347
* Teach CXXScopeSpec to handle the extension of a nested-name-specifierDouglas Gregor2011-02-244-91/+188
| | | | | | | | | with another component in the nested-name-specifiers, updating its representation (a NestedNameSpecifier) and source-location information (currently a SourceRange) simultaneously. This is groundwork for adding source-location information to nested-name-specifiers. llvm-svn: 126346
* Handle value dependent LHS as well as RHS. Test both of these, theyChandler Carruth2011-02-241-1/+1
| | | | | | | | don't seem to have been covered by our tests previously. This should fix bootstrap failure. llvm-svn: 126345
* Implement a warning for known shift overflows on constant shiftChandler Carruth2011-02-231-16/+56
| | | | | | | | | | | | | | | | | | | | | | | expressions. Consider the code: int64_t i = 10 << 30; This compiles fine, but most developers expect it to produce the value for 10 gigs, not -2 gigs. This is actually undefined behavior because the LHS is a signed integer type. The warning is currently gated behind -Wshift-overflow. There is a special case where only the sign bit is overridden that gets a custom error message and is by default ignored. This case is much less likely to cause observed buggy behavior, it's just undefined behavior according to the spec. This warning can be enabled with -Wshift-sign-overflow. Original patch by Oleg Slezberg, with style tweaks and some correctness fixes by me. llvm-svn: 126342
* Fix bogus -Warray-bounds warning involving 'array[true]' reported in PR 9296.Ted Kremenek2011-02-231-1/+1
| | | | llvm-svn: 126341
OpenPOWER on IntegriCloud