Skip to content
  1. Feb 17, 2012
    • Douglas Gregor's avatar
      Rework the Sema/AST/IRgen dance for the lambda closure type's · 355efbb2
      Douglas Gregor authored
      conversion to function pointer. Rather than having IRgen synthesize
      the body of this function, we instead introduce a static member
      function "__invoke" with the same signature as the lambda's
      operator() in the AST. Sema then generates a body for the conversion
      to function pointer which simply returns the address of __invoke. This
      approach makes it easier to evaluate a call to the conversion function
      as a constant, makes the linkage of the __invoke function follow the
      normal rules for member functions, and may make life easier down the
      road if we ever want to constexpr'ify some of lambdas.
      
      Note that IR generation is responsible for filling in the body of
      __invoke (Sema just adds a dummy body), because the body can't
      generally be expressed in C++.
      
      Eli, please review!
      
      llvm-svn: 150783
      355efbb2
  2. Feb 16, 2012
  3. Feb 15, 2012
    • John McCall's avatar
      Split reinterpret_casts of member pointers out from CK_BitCast; this · c62bb391
      John McCall authored
      is general goodness because representations of member pointers are
      not always equivalent across member pointer types on all ABIs
      (even though this isn't really standard-endorsed).
      
      Take advantage of the new information to teach IR-generation how
      to do these reinterprets in constant initializers.  Make sure this
      works when intermingled with hierarchy conversions (although
      this is not part of our motivating use case).  Doing this in the
      constant-evaluator would probably have been better, but that would
      require a *lot* of extra structure in the representation of
      constant member pointers:  you'd really have to track an arbitrary
      chain of hierarchy conversions and reinterpretations in order to
      get this right.  Ultimately, this seems less complex.  I also
      wasn't quite sure how to extend the constant evaluator to handle
      foldings that we don't actually want to treat as extended
      constant expressions.
      
      llvm-svn: 150551
      c62bb391
  4. Feb 14, 2012
  5. Feb 13, 2012
  6. Feb 12, 2012
    • Sebastian Redl's avatar
      Represent C++ direct initializers as ParenListExprs before semantic analysis · a935179a
      Sebastian Redl authored
      instead of having a special-purpose function.
      
      - ActOnCXXDirectInitializer, which was mostly duplication of
        AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
        ago), is dropped completely.
      - MultiInitializer, which was an ugly hack I added, is dropped again.
      - We now have the infrastructure in place to distinguish between
        int x = {1};
        int x({1});
        int x{1};
      -- VarDecl now has getInitStyle(), which indicates which of the above was used.
      -- CXXConstructExpr now has a flag to indicate that it represents list-
         initialization, although this is not yet used.
      - InstantiateInitializer was renamed to SubstInitializer and simplified.
      - ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
        always produces a ParenListExpr. Placed that so far failed to convert that
        back to a ParenExpr containing comma operators have been fixed. I'm pretty
        sure I could have made a crashing test case before this.
      
      The end result is a (I hope) considerably cleaner design of initializers.
      More importantly, the fact that I can now distinguish between the various
      initialization kinds means that I can get the tricky generalized initializer
      test cases Johannes Schaub supplied to work. (This is not yet done.)
      
      This commit passed self-host, with the resulting compiler passing the tests. I
      hope it doesn't break more complicated code. It's a pretty big change, but one
      that I feel is necessary.
      
      llvm-svn: 150318
      a935179a
  7. Feb 11, 2012
  8. Feb 10, 2012
  9. Feb 09, 2012
  10. Feb 08, 2012
Loading