Skip to content
  1. Mar 20, 2009
  2. Mar 17, 2009
  3. Mar 01, 2009
  4. Feb 28, 2009
  5. Feb 27, 2009
  6. Feb 25, 2009
  7. Feb 24, 2009
  8. Feb 18, 2009
  9. Feb 12, 2009
  10. Feb 09, 2009
  11. Feb 04, 2009
  12. Feb 02, 2009
  13. Jan 30, 2009
    • Douglas Gregor's avatar
      Upgrade the "excess elements in array initializer" warning to an · d42a0fb4
      Douglas Gregor authored
      error, since both C99 and C++ consider it an error. For reference, GCC
      makes this a warning while G++ makes it an error.
      
      llvm-svn: 63435
      d42a0fb4
    • Douglas Gregor's avatar
      Implement and test aggregate initialization in C++. Major changes: · d14247a9
      Douglas Gregor authored
        - Support initialization of reference members; complain if any
        reference members are left uninitialized.
        - Use C++ copy-initialization for initializing each element (falls
        back to constraint checking in C)
        - Make sure we diagnose when one tries to provide an initializer
        list for a non-aggregate.
        - Don't complain about empty initializers in C++ (they are permitted)
        - Unrelated but necessary: don't bother trying to convert the
        decl-specifier-seq to a type when we're dealing with a C++
        constructor, destructor, or conversion operator; it results in
        spurious warnings.
      
      llvm-svn: 63431
      d14247a9
    • Douglas Gregor's avatar
      Switch Type::isAggregateType to use the C++ definition of "aggregate · ddb2485e
      Douglas Gregor authored
      type" rather than the C definition. We do this because both C99 and
      Clang always use "aggregate type" as "aggregate or union type", and
      the C++ definition includes union types.
      
      llvm-svn: 63395
      ddb2485e
  14. Jan 29, 2009
  15. Jan 28, 2009
    • Douglas Gregor's avatar
      Code generation support for C99 designated initializers. · 347f7eab
      Douglas Gregor authored
      The approach I've taken in this patch is relatively straightforward,
      although the code itself is non-trivial. Essentially, as we process
      an initializer list we build up a fully-explicit representation of the
      initializer list, where each of the subobject initializations occurs
      in order. Designators serve to "fill in" subobject initializations in
      a non-linear way. The fully-explicit representation makes initializer
      lists (both with and without designators) easy to grok for codegen and
      later semantic analyses. We keep the syntactic form of the initializer
      list linked into the AST for those clients interested in exactly what
      the user wrote.
      
      Known limitations:
        - Designating a member of a union that isn't the first member may
          result in bogus initialization (we warn about this)
        - GNU array-range designators are not supported (we warn about this)
      
      llvm-svn: 63242
      347f7eab
  16. Jan 27, 2009
  17. Jan 23, 2009
Loading