Skip to content
  1. Jul 13, 2009
  2. Jul 11, 2009
    • Daniel Dunbar's avatar
      Fix type conversion of ObjCObjectPointerType. · 7e5f0527
      Daniel Dunbar authored
       - Previous code was based on a misunderstanding (on my part) of the type
         representation.
      
      llvm-svn: 75385
      7e5f0527
    • Daniel Dunbar's avatar
      Generate correct prototype for objc_enumerationMutation. · 9d82da40
      Daniel Dunbar authored
       - This was a latent bug exposed by the recent objc type changes.
      
      llvm-svn: 75383
      9d82da40
    • Eli Friedman's avatar
      Fix typo (found by gcc warning). · 55179ca5
      Eli Friedman authored
      llvm-svn: 75325
      55179ca5
    • Steve Naroff's avatar
      This patch includes a conceptually simple, but very intrusive/pervasive change. · 7cae42b0
      Steve Naroff authored
      The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches.
      
      This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic.
      
      By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time. 
      
      Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks.
      
      llvm-svn: 75314
      7cae42b0
  3. Jul 10, 2009
  4. Jul 08, 2009
  5. Jul 06, 2009
  6. Jul 03, 2009
  7. Jul 02, 2009
  8. Jul 01, 2009
  9. Jun 30, 2009
    • Argyrios Kyrtzidis's avatar
      De-ASTContext-ify DeclContext. · cfbfe78e
      Argyrios Kyrtzidis authored
      Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
      Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
      
      llvm-svn: 74506
      cfbfe78e
    • Argyrios Kyrtzidis's avatar
      Remove the ASTContext parameter from the getBody() methods of Decl and subclasses. · ddcd132a
      Argyrios Kyrtzidis authored
      Timings showed no significant difference before and after the commit.
      
      llvm-svn: 74504
      ddcd132a
    • Argyrios Kyrtzidis's avatar
      Remove the ASTContext parameter from the attribute-related methods of Decl. · b4b64ca7
      Argyrios Kyrtzidis authored
      The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.
      
      This commit touches a lot of files since call sites for these methods are everywhere.
      I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.
      
      llvm-svn: 74501
      b4b64ca7
    • Chris Lattner's avatar
      Key decisions about 'bool' vs '_Bool' to be based on a new flag in langoptions. · c61089a6
      Chris Lattner authored
      This is simple enough, but then I thought it would be nice to make PrintingPolicy
      get a LangOptions so that various things can key off "bool" and "C++" independently.
      This spiraled out of control.  There are many fixme's, but I think things are slightly
      better than they were before.
      
      One thing that can be improved: CFG should probably have an ASTContext pointer in it,
      which would simplify its clients.
      
      llvm-svn: 74493
      c61089a6
    • Douglas Gregor's avatar
      Improve code generation for function template specializations: · e8925dbc
      Douglas Gregor authored
        - Track implicit instantiations vs. the not-yet-supported explicit
        specializations
        - Give implicit instantiations of function templates (and member
        functions of class templates) linkonce_odr linkage.
        - Improve name mangling for function template specializations,
        including the template arguments of the instantiation and the return
        type of the function.
      
      Note that our name-mangling is improved, but not correct: we still
      don't mangle substitutions, although the manglings we produce can be
      demangled.
      
      llvm-svn: 74466
      e8925dbc
  10. Jun 29, 2009
  11. Jun 28, 2009
  12. Jun 26, 2009
  13. Jun 24, 2009
  14. Jun 23, 2009
  15. Jun 20, 2009
  16. Jun 18, 2009
  17. Jun 17, 2009
Loading