Skip to content
  • John McCall's avatar
    A compound literal within a global lambda or block is still within · 2a210ccd
    John McCall authored
    the body of a function for the purposes of computing its storage
    duration and deciding whether its initializer must be constant.
    
    There are a number of problems in our current treatment of compound
    literals.  C specifies that a compound literal yields an l-value
    referring to an object with either static or automatic storage
    duration, depending on where it was written; in the latter case,
    the literal object has a lifetime tied to the enclosing scope (much
    like an ObjC block), not the enclosing full-expression.  To get these
    semantics fully correct in our current design, we would need to
    collect compound literals on the ExprWithCleanups, just like we do
    with ObjC blocks; we would probably also want to identify literals
    like we do with materialized temporaries.  But it gets stranger;
    GCC adds compound literals to C++ as an extension, but makes them
    r-values, which are generally assumed to have temporary storage
    duration.  Ignoring destructor ordering, the difference only matters
    if the object's address escapes the full-expression, which for an
    r-value can only happen with reference binding (which extends
    temporaries) or array-to-pointer decay (which does not).  GCC then
    attempts to lock down on array-to-pointer decay in ad hoc ways.
    Arguably a far superior language solution for C++ (and perhaps even
    array r-values in C, which can occur in other ways) would be to
    propagate lifetime extension through array-to-pointer decay, so
    that initializing a pointer object to a decayed r-value array
    extends the lifetime of the complete object containing the array.
    But this would be a major change in semantics which arguably ought
    to be blessed by the committee(s).
    
    Anyway, I'm not fixing any of that in this patch; I did try, but
    it got out of hand.
    
    Fixes rdar://28949016.
    
    git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285643 91177308-0d34-0410-b5e6-96231b3b80d8
    2a210ccd