[cfe-dev] Missing lvalue-to-rvalue cast for first arg of ->* ?

Enea Zaffanella zaffanella at cs.unipr.it
Thu Jun 30 12:17:17 PDT 2011


Il 30/06/2011 19:16, John McCall ha scritto:
> On Jun 30, 2011, at 1:55 AM, Enea Zaffanella wrote:
>> When dumping the AST for the following C++ program:
>>
>> struct B { int mem; };
>>
>> void foo(B* pb, int B::* pmem) {
>>  pb->mem;
>>  pb->*pmem;
>> }
>>
>> it can be seen that the lvalue pointer pd, when used as the first
>> argument of MemberExpr pb->mem, is subject to an LValueToRValue implicit
>> cast.
>>
>> This is not the case when pb is used as the first argument in the
>> member-pointer operator ->*.
>>
>> Similarly, lvalue member-pointers (such as pmem) occurring as the second
>> argument of ->* and .* operators are not subject to LValueToRValue
>> implicit casts.
>>
>> Is this difference meant (and why)?
> 
> No, it isn't.  Thanks for pointing it out;  fixed in r134170.
> 
> John.
> 

Thank you for the very quick fix!

I have another question, regarding the AST structure of
CXXPseudoDestructorExpr nodes.

==============
template <class T> class Node {
  void bar() { this->~Node<T>(); }
};

template <class T>
void foo(Node<T>* n) { n->~Node<T>(); }
==============

In method bar(), the "destructed type" (i.e., Node<T> after the tilde)
is a TemplateSpecializationTypeLoc (TSTLoc, for short), which is fine.

In function foo(), parameter n is declared to be a TSTLoc,
but the destructed type is a DependentTemplateSpecializationTypeLoc
(DTSTLoc).

I think I have read some comments in the sources telling that this is
quite a dark corner of the standard ... anyway what is surprising to me
is the fact that in foo() we have a DTSTLoc node with *NO* nested name
specifier. I was under the impression that a DTSTLoc should always have
a non-empty NNS.

So, the questions are:

  a) is the DTSTLoc in foo() be considered OK?

and, in case the answer to a) is positive,

  b) are there other context (different from CXXPseudoDestructorExpr)
where a DTSTLoc can have no NNS at all?

Thanks in advance for clarifications.

Cheers,
Enea.



More information about the cfe-dev mailing list