Skip to content
  1. May 01, 2010
  2. Apr 30, 2010
  3. Apr 29, 2010
    • Douglas Gregor's avatar
      When determining a standard conversion sequence involves resolving the · 980fb16f
      Douglas Gregor authored
      address of an overloaded function (or function template), perform that
      resolution prior to determining the implicit conversion
      sequence. This resolution is not part of the implicit conversion
      sequence itself.
      
      Previously, we would always consider this resolution to be a
      function pointer decay, which was a lie: there might be an explicit &
      in the expression, in which case decay should not occur. This caused
      the CodeGen assertion in PR6973 (where we created a 
      pointer to a pointer to a function when we should have had a pointer
      to a function), but it's likely that there are corner cases of
      overload resolution where this would have failed.
      
      Cleaned up the code involved in determining the type that will
      produced afer resolving the overloaded function reference, and added
      an assertion to make sure the result is correct. Fixes PR6973.
      
      llvm-svn: 102650
      980fb16f
    • Fariborz Jahanian's avatar
      Properties cannot be synthesized by-dafult in · 9e1a3af0
      Fariborz Jahanian authored
      categories. Issue usual warnings instead of
      confusing error message. Radar 7920807
      
      llvm-svn: 102645
      9e1a3af0
    • Devang Patel's avatar
      Use clang::VarDecl name instead of llvm::GlobalVariable name. · dfcd0661
      Devang Patel authored
      llvm::GLobalVariable name may not match user visibile name for function static variables.
      
      llvm-svn: 102644
      dfcd0661
    • Nate Begeman's avatar
      Start stamping out the __builtin_neon stuff. · 23a2f2ff
      Nate Begeman authored
      llvm-svn: 102638
      23a2f2ff
Loading