Re: [C++ RFC/Patch] PR 34938

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi again,

On 08/23/2014 09:16 AM, Paolo Carlini wrote:
> .. on the other hand, the below is a case which my patchlet, which 
> simply tracks pointers, does *not* handle correctly:
>
> struct B { };
> template <class T> struct A { };
> A<void(B::*)()const>*p = 42;
>
> should be fixable by complicating a bit the tracking, telling apart 
> member pointers.
Thus I finished testing the below. I separated to a new pr34938-2.C all 
the cases which 4.9 is already getting right and on which we don't want 
to regress.

As you can see, in order to handle correctly snippets like the above in 
pr34938-2.C, I added to the pointer check a check TREE_CODE (t) == 
FUNCTION_TYPE, close to the original idea... For a while that made me a 
little nervous because I was afraid that we would not print the 
attribute for member function pointers when we should, but in fact, as 
we ignore it for typedefs of such types (as I reported a couple of 
messages ago), we also appear to drop to the floor when no typedefs are 
involved, thus, eg we simply accept:

struct A { template<int> void foo(); };

template<void (A::*)() __attribute((noreturn))> void bar();

fptr f1 = bar< &A::foo<0> >;

and if we butcher it a little bit to force an error message (eg, we 
change A::foo to be const) there is no trace of the attribute in the 
error message anyway. Thus I *think* that given our current status 
elsewhere at least, we are fine.

Thanks,
Paolo.

////////////////////////

Attachment: patch_34938_3
Description: Text document