summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
* Moved CollectObjCIvars to more commonly available placeFariborz Jahanian2009-03-051-2/+2
| | | | | | for future use. llvm-svn: 66184
* rename PrettyStackTraceDecl -> PrettyStackTraceActionsDecl.Chris Lattner2009-03-051-0/+22
| | | | | | | | | | | | | | | | Introduce a new PrettyStackTraceDecl. Use it to add the top level LLVM IR generation stuff in Backend.cpp to stack traces. We now get crashes like: Stack dump: 0. Program arguments: clang t.c -emit-llvm 1. <eof> parser at end of file 2. t.c:1:5: LLVM IR generation of declaration 'a' Abort for IR generation crashes. llvm-svn: 66153
* Switch attributes to be allocated from the declcontext bump pointer just likeChris Lattner2009-03-041-0/+11
| | | | | | | decls. This reduces the number of calls to malloc on cocoa.h with pth and -disable-free from 15958 to 12444 times (down ~3500). llvm-svn: 66023
* add an a Attr::Destroy method and force clients to go through it. As part of Chris Lattner2009-03-041-10/+13
| | | | | | this, make DeclBase::Destroy destroy attributes instead of the DeclBase dtor. llvm-svn: 66020
* Minor cleanup for choose expressions: add a helper that returns the Eli Friedman2009-03-042-17/+5
| | | | | | chosen sub-expression, rather than just evaluating the condition. llvm-svn: 66018
* Change Parser::ParseCaseStatement to use an iterative approach to parsingChris Lattner2009-03-042-6/+5
| | | | | | | | | | | | | | | | | | multiple sequential case statements instead of doing it with recursion. This fixes a problem where we run out of stack space parsing 100K directly nested cases. There are a couple other problems that prevent this from being useful in practice (right now the example only parses correctly with -disable-free and doesn't work with -emit-llvm), but this is a start. I'm not including a testcase because it is large and uninteresting for regtesting. Sebastian, I would appreciate it if you could scrutinize the smart pointer gymnastics I do. llvm-svn: 66011
* Fix <rdar://problem/6640991> Exception handling executes wrong clause ↵Steve Naroff2009-03-032-5/+5
| | | | | | | | | | | (Daniel, please verify). Also necessary to fix: <rdar://problem/6632061> [sema] non object types should not be allowed in @catch statements <rdar://problem/6252237> [sema] qualified id should be disallowed in @catch statements llvm-svn: 65964
* Implement the basics of implicit instantiation of class templates, inDouglas Gregor2009-03-031-0/+1
| | | | | | | | | | | | | | | | | | | | response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
* improve compatibility with GCC 4.4, patch by Michel Salim (PR3697)Chris Lattner2009-03-021-0/+1
| | | | llvm-svn: 65884
* Rework the way we find locally-scoped external declarations when weDouglas Gregor2009-03-021-0/+41
| | | | | | | | | | | need them to evaluate redeclarations or call a function that hasn't already been declared. We now keep a DenseMap of these locally-scoped declarations so that they are not visible but can be quickly found, e.g., when we're looking for previous declarations or before we go ahead and implicitly declare a function that's being called. Fixes PR3672. llvm-svn: 65792
* Fix <rdar://problem/6619539> incompatible pointer types sending ↵Steve Naroff2009-03-012-26/+35
| | | | | | | | | 'XCElementSpacer *', expected 'XCElement *' (not handling protocol signatures correctly?). - Reworked ASTContext::canAssignObjCInterfaces(). - Added ObjCProtocolDecl::lookupProtocolNamed(). llvm-svn: 65773
* ObjCAtCatchStmt's ParamStmt is always a DeclStmt.Daniel Dunbar2009-03-011-1/+2
| | | | llvm-svn: 65759
* "This patch addresses two FIXME on ObjCCategoryImplDecl:Chris Lattner2009-02-281-56/+6
| | | | | | | | | | | | | /// FIXME: Like ObjCImplementationDecl, this should not be a NamedDecl! /// FIXME: Introduce a new common base class for ObjCImplementationDecl and ObjCCategoryImplDecl It adds an IndentifierInfo ivar to the ObjCCategoryImplDecl, so it can inherits from Decl and not NamedDecl (I'm not sure about the memory management of this ivar). And now that both ObjCImplementationDecl and ObjCCategoryImplDecl have the same super classes, it allow creation of a common base class: ObjCImplDecl" Patch by Jean-Daniel Dupas! llvm-svn: 65703
* Fix obvious shortcoming in the implementations of Evaluate for Eli Friedman2009-02-281-3/+19
| | | | | | integer __real__ and __imag__. Not sure how I missed this. llvm-svn: 65677
* Eliminate CXXRecordTypeDouglas Gregor2009-02-283-22/+11
| | | | llvm-svn: 65671
* Fix enumeration in switch warnings, plus misc comment changes. No Eli Friedman2009-02-271-2/+41
| | | | | | behavior change. llvm-svn: 65658
* Silence warnings.Mike Stump2009-02-271-2/+2
| | | | llvm-svn: 65644
* Change the AST generated for offsetof a bit so that it looks like a Eli Friedman2009-02-273-46/+11
| | | | | | | | normal expression, and change Evaluate and IRGen to evaluate it like a normal expression. This simplifies the code significantly, and fixes PR3396. llvm-svn: 65622
* Some minor improvements to Evaluate.Eli Friedman2009-02-271-3/+23
| | | | llvm-svn: 65613
* Make isICE assert when Evaluate can't evaluate an ICE, as suggested byEli Friedman2009-02-271-26/+58
| | | | | | | Daniel. Some minor fixes/cleanup. Allow __builtin_choose_expr, __real__, and __imag__ in ICEs, following gcc's example. llvm-svn: 65610
* The middle operand in ?: is optional, really.Mike Stump2009-02-271-1/+1
| | | | llvm-svn: 65609
* Create a new TypeNodes.def file that enumerates all of the types,Douglas Gregor2009-02-267-101/+140
| | | | | | | | | | | | | | | | | | | | | | | | | giving them rough classifications (normal types, never-canonical types, always-dependent types, abstract type representations) and making it far easier to make sure that we've hit all of the cases when decoding types. Switched some switch() statements on the type class over to using this mechanism, and filtering out those things we don't care about. For example, CodeGen should never see always-dependent or non-canonical types, while debug info generation should never see always-dependent types. More switch() statements on the type class need to be moved over to using this approach, so that we'll get warnings when we add a new type then fail to account for it somewhere in the compiler. As part of this, some types have been renamed: TypeOfExpr -> TypeOfExprType FunctionTypeProto -> FunctionProtoType FunctionTypeNoProto -> FunctionNoProtoType There shouldn't be any functionality change... llvm-svn: 65591
* make ASTContext::WCharTy a bit more sensical. In C++, it is a disctint type,Chris Lattner2009-02-261-12/+4
| | | | | | but in C99 it is just another int type. llvm-svn: 65590
* ok, not as broken as I thought, just confusing. This allows Chris Lattner2009-02-261-2/+0
| | | | | | | initialization of wchar_t arrays with wide strings, and generalizes wchar_size.c to work on all targets. llvm-svn: 65586
* Do not issue bogus error on __weak/__strong ivar access.Fariborz Jahanian2009-02-261-3/+3
| | | | llvm-svn: 65583
* Make the type associated with a ClassTemplateSpecializationDecl be aDouglas Gregor2009-02-265-10/+30
| | | | | | | | nicely sugared type that shows how the user wrote the actual specialization. This sugared type won't actually show up until we start doing instantiations. llvm-svn: 65577
* Add Type::hasPointerRepresentation predicate.Daniel Dunbar2009-02-261-8/+2
| | | | | | | | | - For types whose native representation is a pointer. - Use to replace ExprConstant.cpp:HasPointerEvalType, CodeGenFunction::isObjCPointerType. llvm-svn: 65569
* Remove PointerLikeType.Daniel Dunbar2009-02-261-19/+3
| | | | | | | - Having pointers and references share a base was not a useful notion. llvm-svn: 65567
* Make more AST nodes and semantic checkers dependent-expression-aware.Sebastian Redl2009-02-261-1/+2
| | | | llvm-svn: 65529
* Fix ObjCInterfaceDecl::lookupInstanceMethod()/lookupClassMethod() to search ↵Steve Naroff2009-02-261-3/+11
| | | | | | | | | | in inherited protocols. Also changed ObjCInterfaceDecl::lookupClassMethod() to look through a categories protocols. Test/patch submitted by Jean-Daniel Dupas (thanks!). llvm-svn: 65526
* Remove short-circuit evaluation and the extension warnings. I'm Eli Friedman2009-02-261-43/+6
| | | | | | | | | pretty sure we want to keep constant expression verification outside of Evaluate. Because of that, the short-circuit evaluation doesn't generally make sense, and the comma warning doesn't make sense in its current form. llvm-svn: 65525
* Rewrite of isIntegerConstantExpr to be centered around Evaluate. This Eli Friedman2009-02-261-326/+172
| | | | | | | | | | | | | | | | | | | | | | | is a rather big change, but I think this is the direction we want to go; the code is significantly shorter now, and it doesn't duplicate Evaluate code. There shouldn't be any visible changes as far as I know. There has been some movement towards putting ICE handling into Evaluate (for example, VerifyIntegerConstantExpression uses Evaluate instead of isICE). This patch is sort of the opposite of the approach, making ICE handling work without Evaluate being aware of it. I think this approach is better because it separates the code that does the constant evaluation from code that's calculating a rather arbitrary predicate. The one thing I don't really like about this patch is that the handling of commas in C99 complicates it signficantly. (Seriously, what was the standards committee thinking when they wrote that part?) I think I've come up with a decent approach, but it doesn't feel ideal. I might add some way to check for evaluated commas from Evaluate in a subsequent patch; that said, it might not be worth bothering. llvm-svn: 65524
* Fixup spacing.Mike Stump2009-02-261-2/+3
| | | | llvm-svn: 65519
* Use RecordFirst/RecordLast range checks in DeclContextDouglas Gregor2009-02-261-1/+1
| | | | llvm-svn: 65489
* Perform additional semantic checking of class templateDouglas Gregor2009-02-251-0/+8
| | | | | | | | | | | | specializations. In particular: - Make sure class template specializations have a "template<>" header, and complain if they don't. - Make sure class template specializations are declared/defined within a valid context. (e.g., you can't declare a specialization std::vector<MyType> in the global namespace). llvm-svn: 65476
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
* C99 DR #316 implies that the function parameter types that are knownDouglas Gregor2009-02-251-2/+6
| | | | | | | | | | only from a function definition (that does not have a prototype) are only used to determine the compatible with other declarations of that same function. In particular, when referencing the function we pretend as if it does not have a prototype. Implement this behavior, which fixes PR3626. llvm-svn: 65460
* first wave of fixes for @encode sema support. This is part of PR3648.Chris Lattner2009-02-242-1/+4
| | | | | | | The big difference here is that (like string literal) @encode has array type, not pointer type. llvm-svn: 65391
* When we're declaring an object or function with linkage, teach nameDouglas Gregor2009-02-241-0/+9
| | | | | | | lookup to skip over names without linkage. This finishes <rdar://problem/6127293>. llvm-svn: 65386
* Improve merging of function declarations. Specifically:Douglas Gregor2009-02-241-0/+5
| | | | | | | | | | | | | | | | - When we are declaring a function in local scope, we can merge with a visible declaration from an outer scope if that declaration refers to an entity with linkage. This behavior now works in C++ and properly ignores entities without linkage. - Diagnose the use of "static" on a function declaration in local scope. - Diagnose the declaration of a static function after a non-static declaration of the same function. - Propagate the storage specifier to a function declaration from a prior declaration (PR3425) - Don't name-mangle "main" llvm-svn: 65360
* We should not generate __weak write barrier on indirect referenceFariborz Jahanian2009-02-231-0/+2
| | | | | | | of a pointer to object; This patch does this odd behavior according to gcc. llvm-svn: 65334
* Revert http://llvm.org/viewvc/llvm-project?view=rev&revision=65244.Steve Naroff2009-02-233-53/+2
| | | | | | Remove support for "Class<P>". Will be making this an error. llvm-svn: 65332
* Add copy assignment operator, caught by doug.Chris Lattner2009-02-231-0/+9
| | | | llvm-svn: 65331
* A few small improvements to Evaluate for stuff I noted in FIXMEs.Eli Friedman2009-02-231-17/+88
| | | | llvm-svn: 65305
* Contains the following (related to problems found while investigting ↵Steve Naroff2009-02-222-9/+36
| | | | | | | | | | <rdar://problem/6497631> Message lookup is sometimes different than gcc's). - Implement instance/class overloading in ObjCContainerDecl (removing a FIXME). This involved hacking NamedDecl::declarationReplaces(), which took awhile to figure out (didn't realize replace was the default). - Changed Sema::ActOnInstanceMessage() to remove redundant warnings when dealing with protocols. For now, I've omitted the "protocol" term in the diagnostic. It simplifies the code flow and wan't always 100% accurate (e.g. "Foo<Prot>" looks in the class interface, not just the protocol). - Changed several test cases to jive with the above changes. llvm-svn: 65292
* More objc gc work. Match gcc's treatment of ivar accessFariborz Jahanian2009-02-221-0/+27
| | | | | | | true a local pointer to objective-c object in generating write barriers. llvm-svn: 65290
* A bit of Evaluate cleanup. Also, a full audit of what's missing that Eli Friedman2009-02-221-22/+33
| | | | | | someone would reasonably expect Evaluate to handle for C/ObjC. llvm-svn: 65284
* Enhance Evaluate to handle ObjC qualified id and class types; as far as Eli Friedman2009-02-222-4/+10
| | | | | | | | I know, these follow the exact same rules as pointers, so I just made them use the same codepath. Someone more familiar with ObjC should double-check this, though. llvm-svn: 65261
* Fix for PR3433: map __alignof__ to preferred alignment. (This was Eli Friedman2009-02-221-1/+1
| | | | | | partially done in r65258.) llvm-svn: 65260
* Improvements to ASTContext::getDeclAlignInBytes; fixes the testcase in Eli Friedman2009-02-222-31/+20
| | | | | | | | | PR3254 and part of PR3433. The isICE changes are necessary to keep the computed results consistent with Evaluate. llvm-svn: 65258
OpenPOWER on IntegriCloud