1. 31 Jan, 2017 1 commit
    • Hans Wennborg's avatar
      Merging r293596: · 1b8468f0
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r293596 | ahatanak | 2017-01-30 18:31:39 -0800 (Mon, 30 Jan 2017) | 7 lines
      
      Handle ObjCEncodeExpr in extractStringLiteralCharacter.
      
      This fixes an assertion failure that occurs later in the function when
      an ObjCEncodeExpr is cast to StringLiteral.
      
      rdar://problem/30111207
      
      ------------------------------------------------------------------------
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_40@293653 91177308-0d34-0410-b5e6-96231b3b80d8
      1b8468f0
  2. 30 Nov, 2016 1 commit
  3. 18 Sep, 2016 2 commits
  4. 15 Sep, 2015 1 commit
  5. 12 May, 2015 1 commit
  6. 06 Nov, 2014 1 commit
  7. 27 Feb, 2014 1 commit
  8. 28 Jan, 2014 1 commit
  9. 04 Jun, 2013 1 commit
  10. 20 Dec, 2012 1 commit
  11. 20 Jun, 2012 1 commit
    • John McCall's avatar
      Restructure how the driver communicates information about the · 260611a3
      John McCall authored
      target Objective-C runtime down to the frontend:  break this
      down into a single target runtime kind and version, and compute
      all the relevant information from that.  This makes it
      relatively painless to add support for new runtimes to the
      compiler.  Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
      available at the driver level as a better and more general
      alternative to -fgnu-runtime and -fnext-runtime.  This new
      concept of an Objective-C runtime also encompasses what we
      were previously separating out as the "Objective-C ABI", so
      fragile vs. non-fragile runtimes are now really modelled as
      different kinds of runtime, paving the way for better overall
      differentiation.
      
      As a sort of special case, continue to accept the -cc1 flag
      -fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
      
      I won't go so far as to say "no functionality change", even
      ignoring the new driver flag, but subtle changes in driver
      semantics are almost certainly not intended.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158793 91177308-0d34-0410-b5e6-96231b3b80d8
      260611a3
  12. 02 Oct, 2011 1 commit
    • John McCall's avatar
      Make -fobjc-nonfragile-abi the -cc1 default, since it's the · d1e40d53
      John McCall authored
      increasingly prevailing case to the point that new features
      like ARC don't even support the fragile ABI anymore.
      
      This required a little bit of reshuffling with exceptions
      because a check was assuming that ObjCNonFragileABI was
      only being set in ObjC mode, and that's actually a bit
      obnoxious to do.
      
      Most, though, it involved a perl script to translate a ton
      of test cases.
      
      Mostly no functionality change for driver users, although
      there are corner cases with disabling language-specific
      exceptions that we should handle more correctly now.
      
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140957 91177308-0d34-0410-b5e6-96231b3b80d8
      d1e40d53
  13. 16 Jun, 2011 1 commit
  14. 17 May, 2011 1 commit
  15. 16 May, 2011 1 commit
  16. 15 May, 2011 1 commit
  17. 14 May, 2011 1 commit
    • Argyrios Kyrtzidis's avatar
      Create proper Objective-C @encoding for C++ classes; fixes rdar://9357400. · 02c5116d
      Argyrios Kyrtzidis authored
      Go through and expand the members of bases into the encoding string (and encode the VTable as well).
      Unlike gcc which expands virtual bases as many times as they appear in the
      hierarchy, clang will only expand them once at the end, to reflect the actual layout.
      
      Note that there doesn't seem to be a way to indicate in the encoding that
      packing/alignment of members is different that normal, in which case
      the encoding will be out-of-sync with the real layout.
      If the runtime switches to just consider the size of types without
      taking into account alignment, we could easily make padding explicit in the
      encoding (e.g. using arrays of chars). The encoding strings would be
      longer then though.
      
      Also encode a flexible array member as array of 0 size, like gcc, not as a pointer.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131365 91177308-0d34-0410-b5e6-96231b3b80d8
      02c5116d
  18. 11 Oct, 2010 3 commits
  19. 15 Dec, 2009 1 commit
  20. 14 Dec, 2009 1 commit
  21. 30 Nov, 2009 1 commit
  22. 23 Nov, 2009 1 commit
  23. 17 Nov, 2009 1 commit
  24. 08 Nov, 2009 1 commit
  25. 22 Jul, 2009 1 commit
  26. 10 Jul, 2009 1 commit
    • Steve Naroff's avatar
      This patch includes a conceptually simple, but very intrusive/pervasive change. · 14108da7
      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.
      
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75314 91177308-0d34-0410-b5e6-96231b3b80d8
      14108da7
  27. 27 Apr, 2009 1 commit
  28. 24 Mar, 2009 1 commit
  29. 28 Dec, 2008 1 commit
  30. 23 Dec, 2008 1 commit
  31. 22 Dec, 2008 1 commit
  32. 21 Dec, 2008 1 commit
  33. 20 Dec, 2008 2 commits
  34. 19 Dec, 2008 2 commits