- Apr 12, 2009
-
-
Sebastian Redl authored
Parse deleted member functions. Parsing member declarations goes through a different code path that I forgot previously. Implement the rvalue reference overload dance for returning local objects. Returning a local object first tries to find a move constructor now. The error message when no move constructor is defined (or is not applicable) and the copy constructor is deleted is quite ugly, though. llvm-svn: 68902
-
-
- Apr 09, 2009
-
-
Douglas Gregor authored
No functionality change (really). llvm-svn: 68726
-
- Mar 30, 2009
-
-
Sebastian Redl authored
llvm-svn: 68021
-
- Mar 29, 2009
-
-
Sebastian Redl authored
Reintroduce r67870 (rval ref overloading), since I can't reproduce any test failures on i386 or x86_64. If this fails for someone, please contact me. llvm-svn: 67999
-
Chris Lattner authored
to work around this. llvm-svn: 67968
-
- Mar 28, 2009
-
-
Chris Lattner authored
pointer. Its purpose in life is to be a glorified void*, but which does not implicitly convert to void* or other OpaquePtr's with a different UID. Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>. Change the entire parser/sema interface to use DeclPtrTy instead of DeclTy*. This makes the C++ compiler enforce that these aren't convertible to other opaque types. We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc, but I don't plan to do that in the short term. The one outstanding known problem with this patch is that we lose the bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to bitmangle the success bit into the low bit of DeclPtrTy. I will rectify this with a subsequent patch. llvm-svn: 67952
-
Anders Carlsson authored
SemaCXX//overload-member-call.cpp SemaCXX//overloaded-operator.cpp SemaTemplate//instantiate-method.cpp llvm-svn: 67912
-
- Mar 27, 2009
-
-
Sebastian Redl authored
llvm-svn: 67870
-
- Mar 24, 2009
-
-
Douglas Gregor authored
of "object type" rather than the C definition of "object type". The difference is that C's "object type" excludes incomplete types such as struct X; However, C's definition also makes it far too easy to use isObjectType as a means to detect incomplete types when in fact we should use other means (e.g., Sema::RequireCompleteType) that cope with C++ semantics, including template instantiation. I've already audited every use of isObjectType and isIncompleteType to ensure that they are doing the right thing for both C and C++, so this is patch does not change any functionality. llvm-svn: 67648
-
- Mar 23, 2009
-
-
Sebastian Redl authored
llvm-svn: 67492
-
- Mar 17, 2009
-
-
Sebastian Redl authored
Almost complete implementation of rvalue references. One bug, and a few unclear areas. Maybe Doug can shed some light on some of the fixmes. llvm-svn: 67059
-
- Mar 14, 2009
-
-
Douglas Gregor authored
always, refactored the existing logic to tease apart the parser action and the semantic analysis shared by the parser and template instantiation. llvm-svn: 66987
-
- Mar 13, 2009
-
-
Douglas Gregor authored
instantiation for binary operators. This change moves most of the operator-overloading code from the parser action ActOnBinOp to a new, parser-independent semantic checking routine CreateOverloadedBinOp. Of particular importance is the fact that CreateOverloadedBinOp does *not* perform any name lookup based on the current parsing context (it doesn't take a Scope*), since it has to be usable during template instantiation, when there is no scope information. Rather, it takes a pre-computed set of functions that are visible from the context or via argument-dependent lookup, and adds to that set any member operators and built-in operator candidates. The set of functions is computed in the parser action ActOnBinOp based on the current context (both operator name lookup and argument-dependent lookup). Within a template, the set computed by ActOnBinOp is saved within the type-dependent AST node and is augmented with the results of argument-dependent name lookup at instantiation time (see TemplateExprInstantiator::VisitCXXOperatorCallExpr). Sadly, we can't fully test this yet. I'll follow up with template instantiation for sizeof so that the real fun can begin. llvm-svn: 66923
-
Douglas Gregor authored
C++ templates. In particular, keep track of the overloaded operators that are visible from the template definition, so that they can be merged with those operators visible via argument-dependent lookup at instantiation time. Refactored the lookup routines for argument-dependent lookup and for operator name lookup, so they can be called without immediately adding the results to an overload set. Instantiation of these expressions is completely wrong. I'll work on that next. llvm-svn: 66851
-
- Feb 28, 2009
-
-
Douglas Gregor authored
llvm-svn: 65671
-
- Feb 27, 2009
-
-
Douglas Gregor authored
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
-
- Feb 26, 2009
-
-
Daniel Dunbar authored
- No functionality change. llvm-svn: 65563
-
- Feb 19, 2009
-
-
Douglas Gregor authored
llvm-svn: 64993
-
- 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
-
-
Steve Naroff authored
- 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
-
Douglas Gregor authored
complex conversions where the conversion between the real types is an integral promotion. This is how G++ handles complex promotions for its complex integer extension. llvm-svn: 64344
-
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 11, 2009
-
-
Douglas Gregor authored
non-type template parameters that are references to functions or pointers to member functions. Did a little bit of refactoring so that these two cases, along with the handling of non-type template parameters that are pointers to functions, are handled by the same path. Also, tweaked FixOverloadedFunctionReference to cope with member function pointers. This is a necessary step for getting all of the fun member pointer conversions working outside of template arguments, too. llvm-svn: 64277
-
Douglas Gregor authored
non-type template parameters of pointer-to-object and pointer-to-function type. The most fun part of this is the use of overload resolution to pick a function from the set of overloaded functions that comes in as a template argument. Also, fixed two minor bugs in this area: - We were allowing non-type template parameters of type pointer to void. - We weren't patching up an expression that refers to an overloaded function set via "&f" properly. We're still not performing complete checking of the expression to be sure that it is referring to an object or function with external linkage (C++ [temp.arg.nontype]p1). llvm-svn: 64266
-
- Feb 09, 2009
-
-
Ted Kremenek authored
llvm-svn: 64162
-
- Feb 07, 2009
-
-
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 05, 2009
-
-
Sebastian Redl authored
llvm-svn: 63866
-
- Feb 04, 2009
-
-
Sebastian Redl authored
llvm-svn: 63779
-
Douglas Gregor authored
into the general name-lookup fold. This cleans up some ugly, not-quite-working code in the handling of operator overloading. llvm-svn: 63735
-
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
-
Douglas Gregor authored
a.k.a. Koenig lookup) in C++. Most of the pieces are in place, but for two: - In an unqualified call g(x), even if the name does not refer to anything in the current scope, we can still find functions named "g" based on ADL. We don't yet have this ability. - ADL will need updating for friend functions and templates. llvm-svn: 63692
-
- Feb 02, 2009
-
-
Douglas Gregor authored
direct-initialization following a user-defined conversion can select any constructor; it just can't employ any user-defined conversions. So we ban those conversions and classify the constructor call based on the relationship between the "from" and "to" types in the conversion. llvm-svn: 63554
-
- Jan 31, 2009
-
-
Douglas Gregor authored
sequence. Previously, we weren't permitting the second step to call copy constructors, which left user-defined conversion sequences surprisingly broken. Now, we perform overload resolution among all of the constructors, but only accept the result if it makes the conversion a standard conversion. Note that this behavior is different from both GCC and EDG (which don't agree with each other, either); I've submitted a core issue on the matter. llvm-svn: 63450
-
- 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 28, 2009
-
-
Sebastian Redl authored
Fix a stupid mistake in UnwrapSimilarPointers that made any two member pointers compatible as long as the pointee was the same. Make a few style corrections as suggested by Chris. llvm-svn: 63215
-
- 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
-