[cfe-dev] (Unexpected) Method type

[Abramo Bagnara]

Il 10/01/2010 16:07, Sebastian Redl ha scritto:
> Abramo Bagnara wrote:
>> Apart clang behaviour reported above (that I suppose it's definitely a
>> bug)
> Yes, but not one in the type system.
>>  the choice to not have a MethodType (or MemberFunctionType)
>> different from FunctionProtoType is deliberate or it's something that
>> should be saned?
>>   
> It's deliberate. I saw no reason to give it a distinct type. A
> MemberPointerType to FunctionProtoType is a pointer to member function.
> The only place where a member function can appear without a pointer to
> it is in call expressions. You can't do anything with the function in
> these cases except call it, so the type system gets along just fine.
> 
> The bug here is that the validation code for & takes a wrong path and
> returns a normal PointerType to FunctionProtoType.

To tell you the truth, I'm a bit perplexed: I think that a non static
method type is something very different from an ordinary function type
and that they should not share the same type.

If we use the same type, comparison of canonical type of a non static
method and canonical type of an ordinary function could wrongly succeeds
and I expect other problems following this path.

Also under a C++ standard perspective I don't see how a non static
method could be considered to have the same type of ordinary function,
they don't have neither the same arguments (because implicit "this"
argument).

The following C++ source (wrongly compiled by clang) is another small
snippet that shows the problems of current approach:

template <typename T>
void p(T, T);

void g();

struct c {
  void h();
  void f() {
    __typeof(h) i;
    return p(i, g);
  }
};