summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
...
* Improvements to the FunctionDecl getters/setters.Anders Carlsson2009-05-141-2/+2
| | | | llvm-svn: 71800
* Fix rdar://6880874 - [sema] crash on array types with different index sizesChris Lattner2009-05-131-1/+6
| | | | llvm-svn: 71634
* Patch to implement ivar synthesis of properties declared in protocolsFariborz Jahanian2009-05-121-10/+40
| | | | | | only and used in class imllementations (objc2 Nonfragile ABI specific). llvm-svn: 71571
* Encapsulate template arguments lists in a new class,Douglas Gregor2009-05-112-20/+48
| | | | | | | | TemplateArgumentList. This avoids the need to pass around pointer/length pairs of template arguments lists, and will eventually make it easier to introduce member templates and variadic templates. llvm-svn: 71517
* Implement the notions of the "current instantiation" and "unknownDouglas Gregor2009-05-111-3/+4
| | | | | | | | | | | | | | | | | | specialization" within a C++ template, and permit name lookup into the current instantiation. For example, given: template<typename T, typename U> struct X { typedef T type; X* x1; // current instantiation X<T, U> *x2; // current instantiation X<U, T> *x3; // not current instantiation ::X<type, U> *x4; // current instantiation X<typename X<type, U>::type, U>: *x5; // current instantiation }; llvm-svn: 71471
* Add ParentMap:getParentIgnoreParens().Ted Kremenek2009-05-111-0/+5
| | | | llvm-svn: 71469
* The canonical declaration of a NULL declaration is NULLDouglas Gregor2009-05-101-0/+3
| | | | llvm-svn: 71409
* Implement the semantics of the injected-class-name within a classDouglas Gregor2009-05-104-1/+104
| | | | | | | | | | | | | | | | | | template. The injected-class-name is either a type or a template, depending on whether a '<' follows it. As a type, the injected-class-name's template argument list contains its template parameters in declaration order. As part of this, add logic for canonicalizing declarations, and be sure to canonicalize declarations used in template names and template arguments. A TagType is dependent if the declaration it references is dependent. I'm not happy about the rather complicated protocol needed to use ASTContext::getTemplateSpecializationType. llvm-svn: 71408
* Implement C++0x nullptr.Sebastian Redl2009-05-106-1/+32
| | | | llvm-svn: 71405
* Remove -fobjc-tight-layout, seems to work!Daniel Dunbar2009-05-071-6/+3
| | | | llvm-svn: 71184
* Start canonicalizing template names. This is not yet complete, but itDouglas Gregor2009-05-071-0/+11
| | | | | | improves type identity with dependent types. llvm-svn: 71152
* Add support for LLLi -> int128 in builtins.defChris Lattner2009-05-071-21/+22
| | | | llvm-svn: 71148
* Back out r70506 (exception spec in AST) again. We won't have exception specs ↵Sebastian Redl2009-05-062-35/+12
| | | | | | until we've had a lot more discussion. llvm-svn: 71125
* Fixes a bug for objc2's gc in the presense of type-casts.Fariborz Jahanian2009-05-051-1/+3
| | | | llvm-svn: 71041
* source-level CFG: have the body for the @synchronized start with its own basicTed Kremenek2009-05-051-1/+12
| | | | | | block. This makes it a little easier for diagnostics generation. llvm-svn: 71037
* Fix subtle bug in ParentMap::isConsumedExpr(): correctly ignore *parents* thatTed Kremenek2009-05-051-1/+1
| | | | | | are ParenExpr or CastExprs. llvm-svn: 71026
* Fix the field count in interface record layout (it was incorrectlyDaniel Dunbar2009-05-041-6/+0
| | | | | | | | | | | | compensating for super classes). This was making the reported class sizes for empty classes very, very wrong. - Also, we now report the size info for an empty class like gcc (as the offset of the start, not as 0, 0). - Add a few more test cases we were mishandling before (padding bit field at end of struct, for example). llvm-svn: 70938
* Add -fobjc-tight-layout.Daniel Dunbar2009-05-041-0/+9
| | | | | | | | | | | | | | | | | | | - This implements gcc style Objective-C interface layout (I think). Currently it is always off, there is no functionality change unless this is passed. For the curious, the deal is that gcc lays out the fields of a subclass as if they were part of the superclass. That is, the subclass fields immediately follow the super class fields instead of being padded to the alignment of the superclass structure. - Currently gcc uses the tight layout in 32-bit and 64-bit modes, and llvm-gcc uses it in 32-bit only, for reasons which aren't clear yet. We probably want to switch to matching gcc, once this makes it through testing... my hope is that we can also fix llvm-gcc in order to maintain compatibility between the compilers. llvm-svn: 70827
* Don't allow clients to traverse into superclass synthesized propertiesDaniel Dunbar2009-05-041-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | via CollectObjCIvars. - In places where we need them, we should have the implementation and access the properties through it. This is a fairly substantial functionality change: 1. @encode no longer encodes synthesized ivars, ever. 2. The ivar layout bitmap no longer encodes information for synthesized ivars in superclasses. Well, actually I had already broken that, but it is intentional now. We are now differing substantially from llvm-gcc and gcc here. However, in my opinion this fundamentally *must* work if non-fragile classes are to work. Without this change, the result of @encode and the ivar layout depend on the order that the implementation is seen in a file (if it is in the same file with its superclass). Since both scenarios should work the same, our behavior is now consistent with gcc behavior as if an implementation is never seen following an implementation of its superclass. Note that #2 is only a functionality change when (A) an implementation appears in the same translation unit with the implementation of its superclass, and (B) the superclass has synthesized ivars. My belief is that this situation does not occur in practice. I am not yet sure of the role/semantics of @encode when synthesized ivars are present... it's use is fairly unsound in a non-fragile world. llvm-svn: 70822
* PR2524: downgrade taking address of expression of type 'void' to an Eli Friedman2009-05-031-5/+11
| | | | | | extension warning. llvm-svn: 70805
* Remove ASTContext::addRecordToClass.Daniel Dunbar2009-05-031-55/+4
| | | | llvm-svn: 70780
* Use ASTRecordLayout for computing ivar offsets instead of shadowDaniel Dunbar2009-05-031-0/+5
| | | | | | | | | | | struct. - We still need to do more lookup than necessary because ivars don't live in a reasonable DeclContext. - The only remaining client of the interface shadow struct is the ivar layout bitmap. llvm-svn: 70756
* Fix a possible memory error, the record layout entry could beDaniel Dunbar2009-05-031-9/+8
| | | | | | | invalidated by layout out the super class, we cannot cache the map entry. llvm-svn: 70693
* Implement the interface/implementation layout distinction.Daniel Dunbar2009-05-031-10/+25
| | | | | | | | | | - These routines should now be independent of the Sema state. - This is nearly zero functionality change, the distinction only matters in the non-fragile ABI, and the consumers that care about this distinction should be using getASTObjCImplementationLayout. llvm-svn: 70692
* Split out getASTObjCImplementationLayoutDaniel Dunbar2009-05-031-7/+20
| | | | | | | | | | | - The difference from getASTObjCInterfaceLayout is that the computes the layout including synthesized ivars. - No functionality change, they currently both compute the same thing -- whether that includes synthesized ivars or not depends on when they get called!!! llvm-svn: 70690
* Remove an unneeded special case.Daniel Dunbar2009-05-031-10/+1
| | | | llvm-svn: 70689
* When determining whether an expression refers to a bit-field, lookDouglas Gregor2009-05-021-4/+10
| | | | | | | | | into the left-hand side of an assignment expression. This completes most of PR3500; the only remaining part is to deal with the GCC-specific implementation-defined behavior for "unsigned long" (and other) bit-fields. llvm-svn: 70623
* Add CFG support for @synchronized. This fixes <rdar://problem/6848820>.Ted Kremenek2009-05-021-3/+11
| | | | llvm-svn: 70620
* Fix crasher in CFG construction when not properly handling ASTs that containTed Kremenek2009-05-021-44/+106
| | | | | | | expressions not yet properly handled by the CFGBuilder. This failure resulted in a null CFGBlock* being used in rare cases (causing a crash). llvm-svn: 70612
* Get rid of CXXDestroyExpr.Anders Carlsson2009-05-012-20/+6
| | | | llvm-svn: 70586
* Rename CXXExprWithCleanup to CXXExprWithTemporaries.Anders Carlsson2009-05-012-8/+9
| | | | llvm-svn: 70584
* Make a home for exception specs in the AST. Now Sema can hook them up.Sebastian Redl2009-04-302-12/+35
| | | | llvm-svn: 70506
* Properly compute the alignment of typedefs that make use of theDouglas Gregor2009-04-302-32/+45
| | | | | | | | | | | | | | "aligned" attribute. Previously, we were skipping over these attributes when we jumped directly to the canonical type. Now, ASTContext::getTypeInfo walks through typedefs and other "non-canonical" types manually, looking for "aligned" attributes on typedefs. As part of this change, I moved the GNU-specific logic (such as determining the alignment of void or of a function pointer) out of the expression evaluator and into ASTContext::getTypeInfo. llvm-svn: 70497
* int128_t is apparently 128-bit aligned on all 64-bit targets, andChris Lattner2009-04-301-7/+5
| | | | | | | not supported on 32-bit targets, so we can define it to be 128-bit aligned there too :) llvm-svn: 70465
* initial support for __[u]int128_t, which should be basicallyChris Lattner2009-04-302-1/+21
| | | | | | | | compatible with VC++ and GCC. The codegen/mangling angle hasn't been fully ironed out yet. Note that we accept int128_t even in 32-bit mode, unlike gcc. llvm-svn: 70464
* Minor simplification; also silences gcc warning.Eli Friedman2009-04-291-1/+1
| | | | llvm-svn: 70406
* PR4103: Silence bogus unused expression warning.Eli Friedman2009-04-291-1/+2
| | | | llvm-svn: 70384
* PR4097: add logic to Evaluate to handle pointer equality comparisons.Eli Friedman2009-04-281-7/+16
| | | | llvm-svn: 70317
* Improve compatibility with GCC regarding inline semantics in GNU89Douglas Gregor2009-04-281-0/+24
| | | | | | | | | | | mode and in the presence of __gnu_inline__ attributes. This should fix both PR3989 and PR4069. As part of this, we now keep track of all of the attributes attached to each declaration even after we've performed declaration merging. This fixes PR3264. llvm-svn: 70292
* CFG: Add "loop back" block for do...while statements.Ted Kremenek2009-04-281-1/+11
| | | | llvm-svn: 70284
* CFG: 'WhileStmts' needs an extra block to indicate the "loop back" path.Ted Kremenek2009-04-281-5/+10
| | | | llvm-svn: 70280
* CFG:Ted Kremenek2009-04-281-11/+17
| | | | | | | | - Add 'LoopTarget' pointer field to CFGBlock. This records if the block is used as the 'loop back' path back to the head of a loop. - For ForStmt, encode the loop back target as the increment code. llvm-svn: 70274
* A couple more small changes which are probably required for Cygwin Eli Friedman2009-04-271-1/+1
| | | | | | builds to work (PR4088). llvm-svn: 70269
* Add a bit more handling for declarations like "int a[*]".Eli Friedman2009-04-261-1/+2
| | | | llvm-svn: 70162
* Implement function-try-blocks. However, there's a very subtle bug that I ↵Sebastian Redl2009-04-262-5/+22
| | | | | | can't track down. llvm-svn: 70155
* Remove getIntegerConstantExprValue in favor of using EvaluateAsInt.Eli Friedman2009-04-262-4/+3
| | | | llvm-svn: 70145
* Make sure to pull in the target builtin records when initialize the AST ↵Douglas Gregor2009-04-261-1/+1
| | | | | | context, even if we're not going to initialize the __builin_* identifiers llvm-svn: 70111
* split ObjC and C++ Statements out into their own headers.Chris Lattner2009-04-261-0/+2
| | | | llvm-svn: 70105
* implement PCH support for the rest of ExprObjC.h, includingChris Lattner2009-04-261-0/+10
| | | | | | the missing bits of ObjCMessageExpr. llvm-svn: 70100
* Change isNullPointerConstant to be strict; hopefully this won't cause Eli Friedman2009-04-251-6/+2
| | | | | | any issues now that we have our own tgmath.h. llvm-svn: 70090
OpenPOWER on IntegriCloud