Skip to content
  1. May 05, 2010
    • Douglas Gregor's avatar
      Reimplement code generation for copying fields in the · 94f9a482
      Douglas Gregor authored
      implicitly-generated copy constructor. Previously, Sema would perform
      some checking and instantiation to determine which copy constructors,
      etc., would be called, then CodeGen would attempt to figure out which
      copy constructor to call... but would get it wrong, or poke at an
      uninstantiated default argument, or fail in other ways.
      
      The new scheme is similar to what we now do for the implicit
      copy-assignment operator, where Sema performs all of the semantic
      analysis and builds specific ASTs that look similar to the ASTs we'd
      get from explicitly writing the copy constructor, so that CodeGen need
      only do a direct translation.
      
      However, it's not quite that simple because one cannot explicit write
      elementwise copy-construction of an array. So, I've extended
      CXXBaseOrMemberInitializer to contain a list of indexing variables
      used to copy-construct the elements. For example, if we have:
      
        struct A { A(const A&); };
        
        struct B {
          A array[2][3];
        };
      
      then we generate an implicit copy assignment operator for B that looks
      something like this:
      
        B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { }
      
      CodeGen will loop over the invented variables i0 and i1 to visit all
      elements in the array, so that each element in the destination array
      will be copy-constructed from the corresponding element in the source
      array. Of course, if we're dealing with arrays of scalars or class
      types with trivial copy-assignment operators, we just generate a
      memcpy rather than a loop.
      
      Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes
      all of its regression tests.
      
      Conspicuously missing from this patch is handling for the exceptional
      case, where we need to destruct those objects that we have
      constructed. I'll address that case separately.
      
      llvm-svn: 103079
      94f9a482
    • Anders Carlsson's avatar
      Use a more appropriate LLVM type for the vtable pointer. · 58fe1756
      Anders Carlsson authored
      llvm-svn: 103078
      58fe1756
    • Douglas Gregor's avatar
      Unbreak CMake build. · ecc60b99
      Douglas Gregor authored
      llvm-svn: 103077
      ecc60b99
    • Chris Lattner's avatar
      fit in 80 cols · 5561bf3d
      Chris Lattner authored
      llvm-svn: 103075
      5561bf3d
    • Alexis Hunt's avatar
      b9f408a8
  2. May 04, 2010
  3. May 03, 2010
Loading