Re: [lambda] Segmentation fault in simple lambda program

[John Freeman <jfreeman08 at gmail dot com>]

John Freeman wrote:
> > +    /* relayout again -- to allow for implicit
> > +     * parameters to have been added to the capture if it was a
> > +     * 'default capture' -- note that this would not be necessary if
> > +     * the stack-pointer variant was implemented -- since the layout
> > +     * would be known.
> > +     * Relayingout here might have nasty effect if one were to query
> > +     * sizeof *this from within the body -- would that even be
> > +     * possible -- *this would refer to the lambda or the enclosing
> > +     * class instance -- if there was one.???
> > +     *
> > +     * NOTE: I think this is a redefinition error; I'm just faking that
> > +     * it isn't by clearing the size node... need to use stack pointer
> > +     * method.  But that will likely bring its own issues -- not with
> > +     * class layout though.
> > +     */
> > +    TYPE_SIZE (type) = NULL_TREE;
> > +    finish_struct_1 (type);
>
> Relaying out the class after the lambda body was parsed is something I 
> had attempted to do, but possibly failed at.  It will absolutely need 
> to be done.

I just inspected my code again.  The call to layout_class_type at the 
beginning of finish_lambda_function_body at semantics.c:5241 was 
intended to recalculate offsets to members in the case of default captures.

Here is the complete order of the pertinent function calls (file 
location has nothing to do with call order; I supply them to help the 
reader to follow):

finish_struct @ parser.c:6985

cp_parser_lambda_body @ parser.c:6992
--> finish_lambda_function_body @ parser.c:7380
----> layout_class_type @ semantics.c:5241

finish_struct_1 @ ???? I don't see this added yet.  I've checked out 
revision 150396.


- John