- Feb 28, 2009
-
-
Douglas Gregor authored
llvm-svn: 65671
-
- Feb 26, 2009
-
-
Sebastian Redl authored
llvm-svn: 65529
-
- Feb 25, 2009
-
-
Douglas Gregor authored
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
-
- Feb 18, 2009
-
-
Douglas Gregor authored
(as GCC does), except when we've performed overload resolution and found an unavailable function: in this case, we actually error. Merge the checking of unavailable functions with the checking for deprecated functions. This unifies a bit of code, and makes sure that we're checking for unavailable functions in the right places. Also, this check can cause an error. We may, eventually, want an option to make "unavailable" warnings into errors. Implement much of the logic needed for C++0x deleted functions, which are effectively the same as "unavailable" functions (but always cause an error when referenced). However, we don't have the syntax to specify deleted functions yet :) llvm-svn: 64955
-
- Feb 17, 2009
-
-
Chris Lattner authored
2 out of 2 people on irc prefer them gone :) llvm-svn: 64749
-
- Feb 12, 2009
-
-
Douglas Gregor authored
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
-
Douglas Gregor authored
This commit adds a new attribute, "overloadable", that enables C++ function overloading in C. The attribute can only be added to function declarations, e.g., int *f(int) __attribute__((overloadable)); If the "overloadable" attribute exists on a function with a given name, *all* functions with that name (and in that scope) must have the "overloadable" attribute. Sets of overloaded functions with the "overloadable" attribute then follow the normal C++ rules for overloaded functions, e.g., overloads must have different parameter-type-lists from each other. When calling an overloaded function in C, we follow the same overloading rules as C++, with three extensions to the set of standard conversions: - A value of a given struct or union type T can be converted to the type T. This is just the identity conversion. (In C++, this would go through a copy constructor). - A value of pointer type T* can be converted to a value of type U* if T and U are compatible types. This conversion has Conversion rank (it's considered a pointer conversion in C). - A value of type T can be converted to a value of type U if T and U are compatible (and are not both pointer types). This conversion has Conversion rank (it's considered to be a new kind of conversion unique to C, a "compatible" conversion). Known defects (and, therefore, next steps): 1) The standard-conversion handling does not understand conversions involving _Complex or vector extensions, so it is likely to get these wrong. We need to add these conversions. 2) All overloadable functions with the same name will have the same linkage name, which means we'll get a collision in the linker (if not sooner). We'll need to mangle the names of these functions. llvm-svn: 64336
-
- Feb 09, 2009
-
-
Sebastian Redl authored
References are not objects; implement this in Type::isObjectType(). llvm-svn: 64152
-
- Feb 07, 2009
-
-
Sebastian Redl authored
llvm-svn: 64029
-
Ted Kremenek authored
- 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
-
- Feb 04, 2009
-
-
Douglas Gregor authored
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
-
- Feb 03, 2009
-
-
Sebastian Redl authored
Pointers to functions don't work yet, and pointers to overloaded functions even less. Also, far too much illegal code is accepted. llvm-svn: 63655
-
- Jan 30, 2009
-
-
Douglas Gregor authored
LookupName et al. Instead, use an enum and a bool to describe its contents. Optimized the C/Objective-C path through LookupName, eliminating any unnecessarily C++isms. Simplify IdentifierResolver::iterator, removing some code and arguments that are no longer used. Eliminated LookupDeclInScope/LookupDeclInContext, moving all callers over to LookupName, LookupQualifiedName, or LookupParsedName, as appropriate. All together, I'm seeing a 0.2% speedup on Cocoa.h with PTH and -disable-free. Plus, we're down to three name-lookup routines. llvm-svn: 63354
-
- Jan 29, 2009
-
-
Chris Lattner authored
redundant #includes. Patch by Anders Johnsen! llvm-svn: 63271
-
Steve Naroff authored
The previous interface was very confusing. This is much more explicit, which will be easier to understand/optimize/convert. The plan is to eventually deprecate both of these functions. For now, I'm focused on performance. llvm-svn: 63256
-
- Jan 28, 2009
-
-
Steve Naroff authored
Even though Sema::LookupDecl() is deprecated, it's still used all over the place. Simplifying the interface will make it easier to understand/optimize/convert. llvm-svn: 63210
-
- Jan 27, 2009
-
-
Chris Lattner authored
.def file for each library. This means that adding a diagnostic to sema doesn't require all the other libraries to be rebuilt. Patch by Anders Johnsen! llvm-svn: 63111
-
- Jan 25, 2009
-
-
Sebastian Redl authored
llvm-svn: 62971
-
- Jan 20, 2009
-
-
Douglas Gregor authored
that every declaration lives inside a DeclContext. Moved several things that don't have names but were ScopedDecls (and, therefore, NamedDecls) to inherit from Decl rather than NamedDecl, including ObjCImplementationDecl and LinkageSpecDecl. Now, we don't store empty DeclarationNames for these things, nor do we try to insert them into DeclContext's lookup structure. The serialization tests are temporarily disabled. We'll re-enable them once we've sorted out the remaining ownership/serialiazation issues between DeclContexts and TranslationUnion, DeclGroups, etc. llvm-svn: 62562
-
- Jan 19, 2009
-
-
Douglas Gregor authored
new DiagnoseIncompleteType. It provides additional information about struct/class/union/enum types when possible, either by pointing to the forward declaration of that type or by pointing to the definition (if we're in the process of defining that type). Fixes <rdar://problem/6500531>. llvm-svn: 62521
-
- Jan 18, 2009
-
-
Sebastian Redl authored
These actions are extremely widely used (identifier expressions and literals); still no performance regression. llvm-svn: 62468
-
- Jan 16, 2009
-
-
rdar://problem/6502934Douglas Gregor authored
with reference type (it should be an lvalue with non-reference type). llvm-svn: 62345
-
Douglas Gregor authored
analysis and AST-building for the cases where we have N != 1 arguments. For N == 1 arguments, we need to finish the C++ implementation of explicit type casts (C++ [expr.cast]). llvm-svn: 62329
-
- Jan 14, 2009
-
-
Douglas Gregor authored
This change refactors and cleans up our handling of name lookup with LookupDecl. There are several aspects to this refactoring: - The criteria for name lookup is now encapsulated into the class LookupCriteria, which replaces the hideous set of boolean values that LookupDecl currently has. - The results of name lookup are returned in a new class LookupResult, which can lazily build OverloadedFunctionDecls for overloaded function sets (and, eventually, eliminate the need to allocate member for OverloadedFunctionDecls) and contains a placeholder for handling ambiguous name lookup (for C++). - The primary entry points for name lookup are now LookupName (for unqualified name lookup) and LookupQualifiedName (for qualified name lookup). There is also a convenience function LookupParsedName that handles qualified/unqualified name lookup when given a scope specifier. Together, these routines are meant to gradually replace the kludgy LookupDecl, but this won't happen until after we have base class lookup (which forces us to cope with ambiguities). - Documented the heck out of name lookup. Experimenting a little with using Doxygen's member groups to make some sense of the Sema class. Feedback welcome! - Fixes some lingering issues with name lookup for nested-name-specifiers, which now goes through LookupName/LookupQualifiedName. llvm-svn: 62245
-
Douglas Gregor authored
Small cleanup in the handling of user-defined conversions. Also, implement an optimization when constructing a call. We avoid recomputing implicit conversion sequences and instead use those conversion sequences that we computed as part of overload resolution. llvm-svn: 62231
-
Ted Kremenek authored
FunctionDecl::setParams() now uses the allocator associated with ASTContext to allocate the array of ParmVarDecl*'s. llvm-svn: 62203
-
- Jan 13, 2009
-
-
Douglas Gregor authored
llvm-svn: 62122
-
- Jan 08, 2009
-
-
Steve Naroff authored
- ObjCContainerDecl's (ObjCInterfaceDecl/ObjCCategoryDecl/ObjCProtocolDecl), ObjCCategoryImpl, & ObjCImplementation are all DeclContexts. - ObjCMethodDecl is now a ScopedDecl (so it can play nicely with DeclContext). - ObjCContainerDecl now does iteration/lookup using DeclContext infrastructure (no more linear search:-) - Removed ASTContext argument to DeclContext::lookup(). It wasn't being used and complicated it's use from an ObjC AST perspective. - Added Sema::ProcessPropertyDecl() and removed Sema::diagnosePropertySetterGetterMismatch(). - Simplified Sema::ActOnAtEnd() considerably. Still more work to do. - Fixed an incorrect casting assumption in Sema::getCurFunctionOrMethodDecl(), now that ObjCMethodDecl is a ScopedDecl. - Removed addPropertyMethods from ObjCInterfaceDecl/ObjCCategoryDecl/ObjCProtocolDecl. This passes all the tests on my machine. Since many of the changes are central to the way ObjC finds it's methods, I expect some fallout (and there are still a handful of FIXME's). Nevertheless, this should be a step in the right direction. llvm-svn: 61929
-
- Jan 05, 2009
-
-
Sebastian Redl authored
Make C++ classes track the POD property (C++ [class]p4) Track the existence of a copy assignment operator. Implicitly declare the copy assignment operator if none is provided. Implement most of the parsing job for the G++ type traits extension. Fully implement the low-hanging fruit of the type traits: __is_pod: Whether a type is a POD. __is_class: Whether a type is a (non-union) class. __is_union: Whether a type is a union. __is_enum: Whether a type is an enum. __is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1). llvm-svn: 61746
-
- Dec 23, 2008
-
-
Douglas Gregor authored
llvm-svn: 61393
-
Douglas Gregor authored
attached to an identifier. Instead, all overloaded functions will be pushed into scope, and we'll synthesize an OverloadedFunctionDecl on the fly when we need it. llvm-svn: 61386
-
Douglas Gregor authored
DeclContext. Instead, just keep the list of currently-active declarations and only build the OverloadedFunctionDecl when we absolutely need it. This is a half-step toward eliminating the need to explicitly build OverloadedFunctionDecls that store sets of overloaded functions. This was suggested by Argiris a while back, and it's a good thing for several reasons: first, it eliminates the messy logic that currently tries to keep the OverloadedFunctionDecl in sync with the declarations that are being added. Second, it will (eventually) eliminate the need to allocate memory for overload sets, which could help performance. Finally, it helps set us up for when name lookup can return multiple (possibly ambiguous) results, as can happen with lookup of class members in C++. Next steps: make the IdentifierResolver store overloads as separate entries in its list rather than replacing them with an OverloadedFunctionDecl now, then see how far we can go toward eliminating OverloadedFunctionDecl entirely. llvm-svn: 61357
-
- Dec 19, 2008
-
-
Douglas Gregor authored
warning. This matches GCC's behavior and addresses <rdar://problem/6458293>. llvm-svn: 61246
-
- Dec 13, 2008
-
-
Sebastian Redl authored
llvm-svn: 60983
-
- Dec 11, 2008
-
-
Douglas Gregor authored
and separates lexical name lookup from qualified name lookup. In particular: * Make DeclContext the central data structure for storing and looking up declarations within existing declarations, e.g., members of structs/unions/classes, enumerators in C++0x enums, members of C++ namespaces, and (later) members of Objective-C interfaces/implementations. DeclContext uses a lazily-constructed data structure optimized for fast lookup (array for small contexts, hash table for larger contexts). * Implement C++ qualified name lookup in terms of lookup into DeclContext. * Implement C++ unqualified name lookup in terms of qualified+unqualified name lookup (since unqualified lookup is not purely lexical in C++!) * Limit the use of the chains of declarations stored in IdentifierInfo to those names declared lexically. * Eliminate CXXFieldDecl, collapsing its behavior into FieldDecl. (FieldDecl is now a ScopedDecl). * Make RecordDecl into a DeclContext and eliminates its Members/NumMembers fields (since one can just iterate through the DeclContext to get the fields). llvm-svn: 60878
-
Douglas Gregor authored
"else" clause, e.g., if (int X = foo()) { } else { if (X) { // warning: X is always zero in this context } } Fixes rdar://6425550 and lets me think about something other than DeclContext. llvm-svn: 60858
-
- Dec 06, 2008
-
-
Douglas Gregor authored
expressions, and value-dependent expressions. This permits us to parse some template definitions. This is not a complete solution; we're missing type- and value-dependent computations for most of the expression types, and we're missing checks for dependent types and type-dependent expressions throughout Sema. llvm-svn: 60615
-
- Dec 04, 2008
-
-
Sebastian Redl authored
llvm-svn: 60557
-
Sebastian Redl authored
llvm-svn: 60542
-
- Dec 03, 2008
-
-
Sebastian Redl authored
llvm-svn: 60503
-