[cfe-dev] Lambda expr AST representation

[Abramo Bagnara]

Il 09/10/2012 15:29, Douglas Gregor ha scritto:
> 
> On Oct 4, 2012, at 2:36 PM, Abramo Bagnara
> <abramo.bagnara at bugseng.com> wrote:
> 
>>>> I'd suggest a slightly different path:
>>>> 
>>>> 1) the closure type FieldDecl has the name (actually a
>>>> pseudo-name) of the captured variable ("this" to refer to
>>>> captured this)
>>>> 
>>>> 2) the FieldDecl uses a bit to represent the fact that fields
>>>> are the fields of the closure type (this means they are
>>>> actually unnamed)
>>>> 
>>>> In this way the source pretty printing is easily doable, the
>>>> semantic info is accurate, no new AST node is needed, CodeGen
>>>> is simpler (it does not need to map DeclRefExpr to
>>>> MemberExpr).
>>>> 
>>>> I've forgot something?
>>> 
>>> That could work... although it would be a bit tricky to find the 
>>> original captured variable given a MemberExpr of this sort.
>> 
>> I've thought to that, but I failed to imagine a case where this is
>> needed.
> 
> It matters a lot for features that care more about the results of
> name lookup than the underlying semantics. For example, libclang's
> clang_findReferencesInFile, which finds all of the references to a
> given declaration, would need to introduce new code to map the fields
> of implicitly-generated MemberExprs back to references to a normal
> variable declaration. In general, these tools expect (reasonably,
> IMO) that a local variable or static data member will be referenced
> with DeclRefExpr, while a non-static data member will be referenced
> with a MemberExpr. That's actually a very nice invariant. Doing as
> you suggest would complicate the invariants for these clients,
> forcing them to deal specifically with lambda captures (which they
> otherwise wouldn't have to consider). And if we have to have the
> complication somewhere, I'd rather it be with the more intelligent
> clients that care about semantics, rather than the clients that only
> care about cross-referencing.

I have a rather different perspective for libclang that IMHO is more
accurate (and congruent with semantic): the variable in body references
the capture list entry (implicit or explicit) while the capture list
entry references the captured variable.

>> Also I've thought that this info would pertain to capture list and
>> not to field. If we need it we might save the FieldDecl* together
>> with the VarDecl* in LambdaExpr::Capture.
> 
> I'd be perfectly fine with adding the FieldDecl* into
> LambdaExpr::Capture, so it's easy to map between the two.
> 
> Elsewhere, you said:
> 
>> I'd suggest a slightly different path:
>> 
>> 1) the closure type FieldDecl has the name (actually a pseudo-name)
>> of the captured variable ("this" to refer to captured this)
> 
> As noted elsewhere, we can't do this exactly. The __name bit could
> work, but I'd prefer that we simply keep these as anonymous fields,
> because the __ names really don't help that much.

I apologize, it seems I've missed the elsewhere where this has been
clarified. Can you explain that? What's the problem having fake names
(marked as fake)?

It would be a pity to not have such names in FieldDecl, this would make
pretty printer job very easy.

>> 2) the FieldDecl uses a bit to represent the fact that fields are
>> the fields of the closure type (this means they are actually
>> unnamed)
> 
> There's no need for this bit; simply check whether the DeclContext of
> the FieldDecl is a lambda class. From that lambda class, you can get
> at the LambdaExpr::Captures, and therefore the names and original
> VarDecls.

Yes this is definitely easily doable if indeed we can't have name in
FieldDecl.

-- 
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com