Skip to content
  1. Apr 10, 2009
    • Douglas Gregor's avatar
      Implementation of pre-compiled headers (PCH) based on lazy · ef84c4b4
      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
      ef84c4b4
  2. Apr 09, 2009
  3. Apr 01, 2009
    • Douglas Gregor's avatar
      Make parsing a semantic analysis a little more robust following Sema · fe3d7d08
      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
      fe3d7d08
  4. Mar 28, 2009
    • Chris Lattner's avatar
      Introduce a new OpaquePtr<N> struct type, which is a simple POD wrapper for a · 83f095cc
      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
      83f095cc
  5. Mar 27, 2009
  6. Mar 19, 2009
    • Douglas Gregor's avatar
      Introduce a representation for types that we referred to via a · 5253768a
      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
      5253768a
  7. Mar 18, 2009
    • Douglas Gregor's avatar
      The scope representation can now be either a DeclContext pointer or a · 6bfde496
      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
      6bfde496
  8. Mar 13, 2009
    • Douglas Gregor's avatar
      Implement template instantiation for several more kinds of expressions: · 0950e41b
      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
      0950e41b
    • Douglas Gregor's avatar
      Improve the representation of operator expressions like "x + y" within · d2b7ef6e
      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
      d2b7ef6e
  9. Mar 11, 2009
  10. Feb 28, 2009
  11. Feb 27, 2009
    • Douglas Gregor's avatar
      Create a new TypeNodes.def file that enumerates all of the types, · deaad8cc
      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
      deaad8cc
  12. Feb 24, 2009
  13. Feb 14, 2009
    • Douglas Gregor's avatar
      Implicitly declare certain C library functions (malloc, strcpy, memmove, · b9063fc1
      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
      b9063fc1
  14. Feb 12, 2009
    • Douglas Gregor's avatar
      Initial implementation of function overloading in C. · 4e5cbdcb
      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
      4e5cbdcb
  15. Feb 07, 2009
  16. Feb 05, 2009
  17. Feb 04, 2009
  18. Feb 03, 2009
  19. Feb 02, 2009
  20. Jan 30, 2009
    • Douglas Gregor's avatar
      Eliminated LookupCriteria, whose creation was causing a bottleneck for · ed8f2887
      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
      ed8f2887
  21. Jan 20, 2009
    • Douglas Gregor's avatar
      Remove ScopedDecl, collapsing all of its functionality into Decl, so · 6e6ad602
      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
      6e6ad602
  22. Jan 17, 2009
  23. Jan 16, 2009
  24. Jan 15, 2009
  25. Jan 14, 2009
    • Douglas Gregor's avatar
      Refactor name lookup. · 34074326
      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
      34074326
Loading