[cfe-dev] Identifiying (successfully resolved) overloaded function references.

[Enea Zaffanella]

Il 30/09/2011 11:57, John McCall ha scritto:
> On Sep 30, 2011, at 2:19 AM, Enea Zaffanella wrote:
>> We would like to identify the DeclRefExpr and MemberExpr AST nodes
>> that have been created by looking up an overloaded function reference.
>> As far as we can tell, there is no way to extract this information
>> from the current AST. (Is such an impression correct?)
> 
> Yes, this information is lost because the OverloadExpr is thrown
> away during resolution.  It wouldn't be difficult to preserve it, though,
> maybe in some sort of side table on the ASTContext.
> 
> That won't catch every instance of overload resolution, though,
> because operators are resolved without creating intermediate notes.
> Is that acceptable?

Good point.

Besides operators, we were also missing the case of constructor calls
implied by CXXConstructExpr (and derived node CXXTemporaryObjectExpr)
and CXXNewExpr nodes: these too require an additional bit (again, no
space consumed).

As for the side table in the ASTContext: that sounds really interesting
and we may consider that option in the near future.
For our immediate needs, it should be enough to track the (successfully
resolved) function/method references that had more than a single
candidate. So we opted for a bitfield named "HadMultipleCandidates".

In order to track the value of the flag from the place where overloading
is resolved to the place where AST nodes are created, the flag needs to
be added to helper classes InitializationSequence and
UserDefinedConversionSequence.

Please find attached a patch for review.

Regards,
Enea.


>> Hence, we would add a Boolean bitfield flag to AST nodes
>>    DeclRefExpr and MemberExpr
>> so as to be able to recognize those that originally were
>>    UnresolvedLookupExpr and UnresolvedMemberExpr
>> and have been changed by Sema method
>>    Sema::FixOverloadedFunctionReference().
>>
>> The new bitfield will be called, e.g.,
>> IsResolvedOverloadedFunctionReference.
>>
>> The addition of the Boolean flag is not going to impact on the memory
>> footprint of the AST, because for both DeclRefExpr and MemberExpr nodes
>> the new flag can be packed with 3 already existing Boolean bitfields.
> 
> I have no problem with this.
> 
> John.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: HadMultipleCandidates.patch
Type: text/x-patch
Size: 48812 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111003/7dbcc551/attachment.bin>