summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
* wrap long lines.Chris Lattner2009-02-161-6/+8
| | | | llvm-svn: 64650
* DeclContext had its "casting machinery" inside the class definition so that ↵Argyrios Kyrtzidis2009-02-161-2/+46
| | | | | | | | if a new declaration context Decl appeared, the necessary changes would be in one place. Since, now, only DeclNodes.def needs to be modified, move things out-of-line and simplify the DeclContext class. llvm-svn: 64630
* Make DeclContexts maintenance a bit easier.Argyrios Kyrtzidis2009-02-161-1/+1
| | | | | | | | | -In DeclNodes.def, only mark as DeclContexts the top classes that directly derive from DeclContext. If the Decl has subclasses, it should be marked with DECL_CONTEXT_BASE. -Use DeclNodes.def to automate the DeclContext::classof and DeclContext::CastTo definitions. llvm-svn: 64629
* fix build on systems where uint64_t != unsigned long longChris Lattner2009-02-151-1/+1
| | | | llvm-svn: 64605
* Fix pasto noticed by Anders Johnsen.Daniel Dunbar2009-02-151-2/+2
| | | | llvm-svn: 64595
* Add -ffreestanding to suppress the implicit declaration of library builtins ↵Douglas Gregor2009-02-142-6/+14
| | | | | | like printf and malloc. Fixes PR3586 llvm-svn: 64566
* Fixed a problem caused by foreward @class useFariborz Jahanian2009-02-141-0/+12
| | | | | | | | which consequently caused a Seg fault. during meta-data generation. It also addresses an issue related to late binding of newly synthesize ivars (when we support it). llvm-svn: 64563
* Add hook to add attributes to function declarations that we knowDouglas Gregor2009-02-143-16/+35
| | | | | | | | | | | | | | | | about, whether they are builtins or not. Use this to add the appropriate "format" attribute to NSLog, NSLogv, asprintf, and vasprintf, and to translate builtin attributes (from Builtins.def) into actual attributes on the function declaration. Use the "printf" format attribute on function declarations to determine whether we should do format string checking, rather than looking at an ad hoc list of builtins and "known" function names. Be a bit more careful about when we consider a function a "builtin" in C++. llvm-svn: 64561
* Fix the build on win32.Cedric Venet2009-02-141-4/+4
| | | | llvm-svn: 64556
* Several related changes: Chris Lattner2009-02-141-38/+103
| | | | | | | | | | | | | | | 1) implement parser and sema support for reading and verifying attribute(warnunusedresult). 2) rename hasLocalSideEffect to isUnusedResultAWarning, inverting the sense of its result. 3) extend isUnusedResultAWarning to directly return the loc and range info that should be reported to the user. Make it substantially more precise in some cases than what was previously reported. 4) teach isUnusedResultAWarning about CallExpr to decls that are pure/const/warnunusedresult, fixing a fixme. 5) change warn_attribute_wrong_decl_type to not pass in english strings, instead, pass in integers and use %select. llvm-svn: 64543
* Make it possible for builtins to expression FILE* arguments, so thatDouglas Gregor2009-02-141-6/+25
| | | | | | | | we can define builtins such as fprintf, vfprintf, and __builtin___fprintf_chk. Give a nice error message when we need to implicitly declare a function like fprintf. llvm-svn: 64526
* Extend builtin "attribute" syntax to include a notation forDouglas Gregor2009-02-141-0/+35
| | | | | | | | | | | | | | | | | | | | | printf-like functions, both builtin functions and those in the C library. The function-call checker now queries this attribute do determine if we have a printf-like function, rather than scanning through the list of "known functions IDs". However, there are 5 functions they are not yet "builtins", so the function-call checker handles them specifically still: - fprintf and vfprintf: the builtins mechanism cannot (yet) express FILE* arguments, so these can't be encoded. - NSLog: the builtins mechanism cannot (yet) express NSString* arguments, so this (and NSLogv) can't be encoded. - asprintf and vasprintf: these aren't part of the C99 standard library, so we really shouldn't be defining them as builtins in the general case (and we don't seem to have the machinery to make them builtins only on certain targets and depending on whether extensions are enabled). llvm-svn: 64512
* Implicitly declare certain C library functions (malloc, strcpy, memmove,Douglas Gregor2009-02-132-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | etc.) when we perform name lookup on them. This ensures that we produce the correct signature for these functions, which has two practical impacts: 1) When we're supporting the "implicit function declaration" feature of C99, these functions will be implicitly declared with the right signature rather than as a function returning "int" with no prototype. See PR3541 for the reason why this is important (hint: GCC always predeclares these functions). 2) If users attempt to redeclare one of these library functions with an incompatible signature, we produce a hard error. This patch does a little bit of work to give reasonable error messages. For example, when we hit case #1 we complain that we're implicitly declaring this function with a specific signature, and then we give a note that asks the user to include the appropriate header (e.g., "please include <stdlib.h> or explicitly declare 'malloc'"). In case #2, we show the type of the implicit builtin that was incorrectly declared, so the user can see the problem. We could do better here: for example, when displaying this latter error message we say something like: 'strcpy' was implicitly declared here with type 'char *(char *, char const *)' but we should really print out a fake code line showing the declaration, like this: 'strcpy' was implicitly declared here as: char *strcpy(char *, char const *) This would also be good for printing built-in candidates with C++ operator overloading. The set of C library functions supported by this patch includes all functions from the C99 specification's <stdlib.h> and <string.h> that (a) are predefined by GCC and (b) have signatures that could cause codegen issues if they are treated as functions with no prototype returning and int. Future work could extend this set of functions to other C library functions that we know about. llvm-svn: 64504
* Remove DeclGroupOwningRef, since we intend for declarations to be ownedDouglas Gregor2009-02-134-57/+5
| | | | | | | | | | | | | | | by DeclContexts (always) rather than by statements. DeclContext currently goes out of its way to avoid destroying any Decls that might be owned by a DeclGroupOwningRef. However, in an error-recovery situation, a failure in a declaration statement can cause all of the decls in a DeclGroupOwningRef to be destroyed after they've already be added into the DeclContext. Hence, DeclContext is left with already-destroyed declarations, and bad things happen. This problem was causing failures that showed up as assertions on x86 Linux in test/Parser/objc-forcollection-neg-2.m. llvm-svn: 64474
* Initial implementation of arbitrary fixed-width integer types. Eli Friedman2009-02-132-11/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently only used for 128-bit integers. Note that we can't use the fixed-width integer types for other integer modes without other changes because glibc headers redefines (u)int*_t and friends using the mode attribute. For example, this means that uint64_t has to be compatible with unsigned __attribute((mode(DI))), and uint64_t is currently defined to long long. And I have a feeling we'll run into issues if we try to define uint64_t as something which isn't either long or long long. This doesn't get the alignment right in most cases, including the 128-bit integer case; I'll file a PR shortly. The gist of the issue is that the targets don't really expose the information necessary to figure out the alignment outside of the target description, so there's a non-trivial amount of work involved in getting it working right. That said, the alignment used is conservative, so the only issue with the current implementation is ABI compatibility. This makes it trivial to add some sort of "bitwidth" attribute to make arbitrary-width integers; I'll do that in a followup. We could also use this for stuff like the following for compatibility with gcc, but I have a feeling it would be a better idea for clang to be consistent between C and C++ modes rather than follow gcc's example for C mode. struct {unsigned long long x : 33;} x; unsigned long long a(void) {return x.x+1;} llvm-svn: 64434
* Several cleanups:Steve Naroff2009-02-121-6/+29
| | | | | | | | - rename isObjCIdType/isObjCClassType -> isObjCIdStructType/isObjCClassStructType. The previous name didn't do what you would expect. - add back isObjCIdType/isObjCClassType to do what you would expect. Not currently used, however many of the isObjCIdStructType/isObjCClassStructType clients could be converted over time. - move static Sema function areComparableObjCInterfaces to ASTContext (renamed to areComparableObjCPointerTypes, since it now operates on pointer types). llvm-svn: 64385
* Fix va_arg bug noticed by Eli, __builtin_va_arg is not an l-valueDaniel Dunbar2009-02-121-1/+1
| | | | | | designating an object. llvm-svn: 64371
* Introduce _Complex conversions into the function overloadingDouglas Gregor2009-02-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | system. Since C99 doesn't have overloading and C++ doesn't have _Complex, there is no specification for this. Here's what I think makes sense. Complex conversions come in several flavors: - Complex promotions: a complex -> complex conversion where the underlying real-type conversion is a floating-point promotion. GCC seems to call this a promotion, EDG does something else. This is given "promotion" rank for determining the best viable function. - Complex conversions: a complex -> complex conversion that is not a complex promotion. This is given "conversion" rank for determining the best viable function. - Complex-real conversions: a real -> complex or complex -> real conversion. This is given "conversion" rank for determining the best viable function. These rules are the same for C99 (when using the "overloadable" attribute) and C++. However, there is one difference in the handling of floating-point promotions: in C99, float -> long double and double -> long double are considered promotions (so we give them "promotion" rank), while C++ considers these conversions ("conversion" rank). llvm-svn: 64343
* Last @encode'ing fix for objc2's nonfragile abi.Fariborz Jahanian2009-02-111-3/+6
| | | | | | All relevant dejagnu enocding tests pass in this mode. llvm-svn: 64341
* Patch to fix encoding in 64bit abi. With this patchFariborz Jahanian2009-02-111-2/+8
| | | | | | | all but one dejagnu encoding tests for darwin pass in nonfragile abi mode. llvm-svn: 64334
* Allow the use of default template arguments when forming a classDouglas Gregor2009-02-111-0/+20
| | | | | | | | | | | | | | template specialization (e.g., std::vector<int> would now be well-formed, since it relies on a default argument for the Allocator template parameter). This is much less interesting than one might expect, since (1) we're not actually using the default arguments for anything important, such as naming an actual Decl, and (2) we'll often need to instantiate the default arguments to check their well-formedness. The real fun will come later. llvm-svn: 64310
* CHAR_BIT == 8Douglas Gregor2009-02-111-2/+2
| | | | llvm-svn: 64286
* Add private extern to pretty printer(s).Mike Stump2009-02-101-5/+6
| | | | llvm-svn: 64258
* Fixup -ast-print so that:Mike Stump2009-02-101-11/+26
| | | | | | | | | | | | | | We handle indentation of decls better. We Indent extern "C" { } stuff better. We print out structure contents more often. We handle pass indentation information into the statement printer, so that nested things come out more indented. We print out FieldDecls. We print out Vars. We print out namespaces. We indent functions better. llvm-svn: 64232
* Refactor FieldDecls to be ValueDecls instead of NamedDecls.Mike Stump2009-02-101-3/+2
| | | | llvm-svn: 64231
* Implement parsing, semantic analysis and ASTs for default templateDouglas Gregor2009-02-101-0/+9
| | | | | | | | | arguments. This commit covers checking and merging default template arguments from previous declarations, but it does not cover the actual use of default template arguments when naming class template specializations. llvm-svn: 64229
* Rudimentary checking of template arguments against their correspondingDouglas Gregor2009-02-091-1/+1
| | | | | | | template parameters when performing semantic analysis of a template-id naming a class template specialization. llvm-svn: 64185
* id<Foo> is a POD type.Anders Carlsson2009-02-091-0/+1
| | | | llvm-svn: 64175
* CallExpr now uses ASTContext's allocate to allocate/delete its array of ↵Ted Kremenek2009-02-092-6/+16
| | | | | | subexpressions. llvm-svn: 64162
* Eliminate TemplateArg so that we only have a single kind ofDouglas Gregor2009-02-092-5/+6
| | | | | | | | | | | | representation for template arguments. Also simplifies the interface for ActOnClassTemplateSpecialization and eliminates some annoying allocations of TemplateArgs. My attempt at smart pointers for template arguments lists is relatively lame. We can improve it once we're sure that we have the right representation for template arguments. llvm-svn: 64154
* Start processing template-ids as types when the template-name refersDouglas Gregor2009-02-094-0/+174
| | | | | | | | | | | | | | | | | | | | | to a class template. For example, the template-id 'vector<int>' now has a nice, sugary type in the type system. What we can do now: - Parse template-ids like 'vector<int>' (where 'vector' names a class template) and form proper types for them in the type system. - Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly, using (sadly) a bool in the parser to tell it whether '>' should be treated as an operator or not. This is a baby-step, with major problems and limitations: - There are currently two ways that we handle template arguments (whether they are types or expressions). These will be merged, and, most likely, TemplateArg will disappear. - We don't have any notion of the declaration of class template specializations or of template instantiations, so all template-ids are fancy names for 'int' :) llvm-svn: 64153
* Update new expression to make use of Declarator::getSourceRange().Sebastian Redl2009-02-091-1/+1
| | | | | | References are not objects; implement this in Type::isObjectType(). llvm-svn: 64152
* Deallocate the StringLiteral itself in StringLiteral::Destroy() and ↵Ted Kremenek2009-02-091-1/+2
| | | | | | deallocate the string data before running StringLiteral's destructor. llvm-svn: 64146
* Allocate the subexpression array for OberloadExpr from ASTContext's allocator.Ted Kremenek2009-02-092-1/+8
| | | | llvm-svn: 64145
* Teach the constant evaluator about C++ const integral variables.Sebastian Redl2009-02-081-1/+10
| | | | llvm-svn: 64086
* Fix pretty-printing of if conditions. Patch by Ben Lickly.Sebastian Redl2009-02-071-1/+2
| | | | llvm-svn: 64027
* Make const-initialized const integral variables I-C-Es in C++.Sebastian Redl2009-02-071-0/+11
| | | | llvm-svn: 64015
* Overhaul of Stmt allocation:Ted Kremenek2009-02-074-25/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Made allocation of Stmt objects using vanilla new/delete a *compiler error* by making this new/delete "protected" within class Stmt. - Now the only way to allocate Stmt objects is by using the new operator that takes ASTContext& as an argument. This ensures that all Stmt nodes are allocated from the same (pool) allocator. - Naturally, these two changes required that *all* creation sites for AST nodes use new (ASTContext&). This is a large patch, but the majority of the changes are just this mechanical adjustment. - The above changes also mean that AST nodes can no longer be deallocated using 'delete'. Instead, one most do StmtObject->Destroy(ASTContext&) or do ASTContextObject.Deallocate(StmtObject) (the latter not running the 'Destroy' method). Along the way I also... - Made CompoundStmt allocate its array of Stmt* using the allocator in ASTContext (previously it used std::vector). There are a whole bunch of other Stmt classes that need to be similarly changed to ensure that all memory allocated for ASTs comes from the allocator in ASTContext. - Added a new smart pointer ExprOwningPtr to Sema.h. This replaces the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used 'delete' to free memory instead of a Stmt's 'Destroy' method. Big thanks to Doug Gregor for helping with the acrobatics of making 'new/delete' private and the new smart pointer ExprOwningPtr! llvm-svn: 63997
* Implement dereferencing of pointers-to-member.Sebastian Redl2009-02-071-0/+6
| | | | llvm-svn: 63983
* Semantic checking for class template declarations andDouglas Gregor2009-02-061-5/+11
| | | | | | | | | | | | | | | redeclarations. For example, checks that a class template redeclaration has the same template parameters as previous declarations. Detangled class-template checking from ActOnTag, whose logic was getting rather convoluted because it tried to handle C, C++, and C++ template semantics in one shot. Made some inroads toward eliminating extraneous "declaration does not declare anything" errors by adding an "error" type specifier. llvm-svn: 63973
* Move StringLiteral to allocate its internal string data using the allocator inTed Kremenek2009-02-062-23/+36
| | | | | | | | | | | ASTContext. This required changing all clients to pass in the ASTContext& to the constructor of StringLiteral. I also changed all allocations of StringLiteral to use new(ASTContext&). Along the way, I updated a bunch of new()'s in StmtSerialization.cpp to use the allocator from ASTContext& (not complete). llvm-svn: 63958
* Use ASTContext's allocator to deallocate Stmt objects instead of using ↵Ted Kremenek2009-02-061-3/+5
| | | | | | 'delete'. This fixes <rdar://problem/6561143>. llvm-svn: 63905
* Improve the representation of template type parameters. We nowDouglas Gregor2009-02-055-34/+49
| | | | | | | | | | | canonicalize by template parameter depth, index, and name, and the unnamed version of a template parameter serves as the canonical. TemplateTypeParmDecl no longer needs to inherit from TemplateParmPosition, since depth and index information is present within the type. llvm-svn: 63899
* Fix the symptom of the regression, by having the CXXConditionDeclExpr not ↵Sebastian Redl2009-02-052-2/+6
| | | | | | | | destroy its Decl. However, the cause still remains: the Decl is linked into the chain of its DeclContext and remains there despite being deleted. llvm-svn: 63868
* Basic representation of C++ class templates, from Andrew Sutton.Douglas Gregor2009-02-048-32/+161
| | | | llvm-svn: 63750
* Some name-lookup-related fixes, from Piotr Rak!Douglas Gregor2009-02-041-0/+36
| | | | | | | | | | | | | - Changes Lookup*Name functions to return NamedDecls, instead of Decls. Unfortunately my recent statement that it will simplify lot of code, was not quite right, but it simplifies some... - Makes MergeLookupResult SmallPtrSet instead of vector, following Douglas suggestions. - Adds %qN format for printing qualified names to Diagnostic. - Avoids searching for using-directives in Scopes, which are not DeclScope, during unqualified name lookup. llvm-svn: 63739
* Fix our semantic analysis ofDouglas Gregor2009-02-043-12/+12
| | | | | | | | | | | | | | | | | | | | | unqualified-id '(' in C++. The unqualified-id might not refer to any declaration in our current scope, but declarations by that name might be found via argument-dependent lookup. We now do so properly. As part of this change, CXXDependentNameExpr, which was previously designed to express the unqualified-id in the above constructor within templates, has become UnresolvedFunctionNameExpr, which does effectively the same thing but will work for both templates and non-templates. Additionally, we cope with all unqualified-ids, since ADL also applies in cases like operator+(x, y) llvm-svn: 63733
* Semantic analysis, ASTs, and unqualified name lookup support for C++Douglas Gregor2009-02-036-4/+68
| | | | | | using directives, from Piotr Rak! llvm-svn: 63646
* Add a macro-based enumeration of all of the Decl nodes (like we doDouglas Gregor2009-02-023-235/+37
| | | | | | | with Stmt/Expr nodes), and convert some of the more mundane switch-on-all-decl-kinds uses over to use this new file. llvm-svn: 63570
* Change the ObjC type encoding for block pointer types to "@?" (for ↵Steve Naroff2009-02-021-1/+1
| | | | | | | | consistency with GCC). This fixes <rdar://problem/6538564> clang ObjC rewriter: Wrong encoding emitted for methods with Block parameters. llvm-svn: 63534
OpenPOWER on IntegriCloud