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

[Paolo Carlini <paolo.carlini@oracle.com>]

Hi,

On 08/22/2014 08:17 PM, Jason Merrill wrote:
> On 08/22/2014 01:53 PM, Paolo Carlini wrote:
>> maybe this old issue is already fixed. We used to ICE on:
>>
>> typedef void (*fptr)() __attribute((noreturn));
>> template<int> void foo();
>> template<fptr> void bar();
>>
>> fptr f = bar< foo<0> >;
>>
>> but lately we simply reject it:
>>
>> 34938.C:5:10: error: no matches converting function ‘bar’ to type ‘fptr
>> {aka void (*)() volatile}’
>> fptr f = bar< foo<0> >;
>> ^
>> 34938.C:3:21: note: candidate is: template<void (* <anonymous>)()
>> volatile> void bar()
>> template<fptr> void bar();
>> ^
>>
>> is that Ok? clang behaves like us, EDG accepts the code.
>
> Well, since the attribute is outside the language, I guess we get to 
> decide what it means; C++11 [[noreturn]] is only defined on decls, not 
> types.
>
> I think rejecting it makes sense; since bar is not declared as 
> noreturn, assigning its address to a noreturn function pointer seems 
> wrong.
Ok, thanks. Good.
>> A secondary
>> issue I noticed is that we print 'volatile' instead of the attribute,
>> that is fixed by the patchlet below.
>
> Currently function-cv-quals on a FUNCTION_TYPE used as a typedef or 
> template parameter have the same encoding as the const and noreturn 
> attributes;
Indeed, this is also my understanding per pp_c_cv_qualifiers.
> to get the printing right you need to know the context of the 
> FUNCTION_TYPE.  If it's the type of a pointer, then the attribute is 
> correct.
Ok. Currently in cases like the present one, dump_type_suffix upon a 
pointer recurses and we end up calling pp_cxx_cv_qualifiers on the given 
FUNCTION_TYPE / METHOD_TYPE. Thus pp_cxx_cv_qualifiers lacks the pointer 
context, just sees the latter. Do you think that the current simple 
setup, thus my patch which just extends it, can be incorrect in some cases?

Thanks,
Paolo.