- Apr 10, 2009
-
-
Douglas Gregor authored
de-serialization of abstract syntax trees. PCH support serializes the contents of the abstract syntax tree (AST) to a bitstream. When the PCH file is read, declarations are serialized as-needed. For example, a declaration of a variable "x" will be deserialized only when its VarDecl can be found by a client, e.g., based on name lookup for "x" or traversing the entire contents of the owner of "x". This commit provides the framework for serialization and (lazy) deserialization, along with support for variable and typedef declarations (along with several kinds of types). More declarations/types, along with important auxiliary structures (source manager, preprocessor, etc.), will follow. llvm-svn: 68732
-
- Apr 09, 2009
-
-
Douglas Gregor authored
No functionality change (really). llvm-svn: 68726
-
- Apr 01, 2009
-
-
Douglas Gregor authored
failures that involve malformed types, e.g., "typename X::foo" where "foo" isn't a type, or "std::vector<void>" that doens't instantiate properly. Similarly, be a bit smarter in our handling of ambiguities that occur in Sema::getTypeName, to eliminate duplicate error messages about ambiguous name lookup. This eliminates two XFAILs in test/SemaCXX, one of which was crying out to us, trying to tell us that we were producing repeated error messages. llvm-svn: 68251
-
- 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
-
- Mar 27, 2009
-
-
Douglas Gregor authored
classes. Test case from Anders Carlsson, fix from Piotr Rak! llvm-svn: 67817
-
- Mar 19, 2009
-
-
Douglas Gregor authored
qualified name, e.g., foo::x so that we retain the nested-name-specifier as written in the source code and can reproduce that qualified name when printing the types back (e.g., in diagnostics). This is PR3493, which won't be complete until finished the other tasks mentioned near the end of this commit. The parser's representation of nested-name-specifiers, CXXScopeSpec, is now a bit fatter, because it needs to contain the scopes that precede each '::' and keep track of whether the global scoping operator '::' was at the beginning. For example, we need to keep track of the leading '::', 'foo', and 'bar' in ::foo::bar::x The Action's CXXScopeTy * is no longer a DeclContext *. It's now the opaque version of the new NestedNameSpecifier, which contains a single component of a nested-name-specifier (either a DeclContext * or a Type *, bitmangled). The new sugar type QualifiedNameType composes a sequence of NestedNameSpecifiers with a representation of the type we're actually referring to. At present, we only build QualifiedNameType nodes within Sema::getTypeName. This will be extended to other type-constructing actions (e.g., ActOnClassTemplateId). Also on the way: QualifiedDeclRefExprs will also store a sequence of NestedNameSpecifiers, so that we can print out the property nested-name-specifier. I expect to also use this for handling dependent names like Fibonacci<I - 1>::value. llvm-svn: 67265
-
- Mar 18, 2009
-
-
Douglas Gregor authored
Type pointer. This allows our nested-name-specifiers to retain more information about the actual spelling (e.g., which typedef did the user name, or what exact template arguments were used in the template-id?). It will also allow us to have dependent nested-name-specifiers that don't map to any DeclContext. llvm-svn: 67140
-
- Mar 13, 2009
-
-
Douglas Gregor authored
- C++ function casts, e.g., T(foo) - sizeof(), alignof() More importantly, this allows us to verify that we're performing overload resolution during template instantiation, with argument-dependent lookup and the "cached" results of name lookup from the template definition. llvm-svn: 66947
-
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
-
- Mar 11, 2009
-
-
Douglas Gregor authored
template. More importantly, start to sort out the issues regarding complete types and nested-name-specifiers, especially the question of: when do we instantiate a class template specialization that occurs to the left of a '::' in a nested-name-specifier? llvm-svn: 66662
-
- 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 24, 2009
-
-
Douglas Gregor authored
lookup to skip over names without linkage. This finishes <rdar://problem/6127293>. llvm-svn: 65386
-
- Feb 14, 2009
-
-
Douglas Gregor authored
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
-
- Feb 12, 2009
-
-
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 07, 2009
-
-
Sebastian Redl authored
llvm-svn: 63983
-
- Feb 05, 2009
-
-
Douglas Gregor authored
Also, put Objective-C protocols into their own identifier namespace. Otherwise, we find protocols when we don't want to in C++ (but not in C). llvm-svn: 63877
-
- Feb 04, 2009
-
-
Douglas Gregor authored
llvm-svn: 63750
-
Douglas Gregor authored
- 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
-
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
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 03, 2009
-
-
Chris Lattner authored
llvm-svn: 63662
-
Douglas Gregor authored
using directives, from Piotr Rak! llvm-svn: 63646
-
- Feb 02, 2009
-
-
Douglas Gregor authored
non-ambiguous name lookup results without allocating any memory, e.g., for sets of overloaded functions. llvm-svn: 63549
-
- 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 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 17, 2009
-
-
Douglas Gregor authored
llvm-svn: 62391
-
Douglas Gregor authored
even when we are still defining the TagDecl. This is required so that qualified name lookup of a class name within its definition works (see the new bits in test/SemaCXX/qualified-id-lookup.cpp). As part of this, move the nested redefinition checking code into ActOnTag. This gives us diagnostics earlier (when we try to perform the nested redefinition, rather than when we try to complete the 2nd definition) and removes some code duplication. llvm-svn: 62386
-
- Jan 16, 2009
-
-
Douglas Gregor authored
llvm-svn: 62287
-
- Jan 15, 2009
-
-
Daniel Dunbar authored
and uninitialized use options. llvm-svn: 62270
-
Douglas Gregor authored
llvm-svn: 62250
-
Douglas Gregor authored
llvm-svn: 62247
-
- 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
-