Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044]

[nick huang <nickhuang99@hotmail.com>]

Hi Jason,

Sorry for not noticing your response.

>>Unfortunately, your patch breaks
>>
>>template <class T>
>>struct A
>>{
>>   void f(T);
>>};
>>template <class T>
>>void A<T>::f(const T)
>>{ }

1. Perhaps I misunderstand your comment, but my patch does NOT fix this issue. Neither does current GCC fix this code, if it is incorrect grammatically. In other words,  tested in www.godbolt.org and all major compilers accept it.  And my patch does NOT affects GCC current behavior, meaning my patched GCC still accepts it like now. So, I don't think my patch breaks it because this code is never fixed. (Whether this code is correct or not, I keep an open mind.)


>>which is certainly questionable code, but is currently also accepted by 
>>clang and EDG compilers.

2. Like I said above, I am not even sure if it is an issue since most compilers accept it. But my patch does NOT touch this issue at all. In essential, my patch ONLY deals with dependent type starting with keyword "typename" or "decltype". Just like my email subject, my patch only fixes one particular case of this "family" of bugs, that is "typename" or "decltype" cases.

>>Why doesn't the PR92010 fix address these testcases as well?

3. PR92010 creates new functions of "rebuild_function_or_method_type" and by using gdb to trace PR101402 code as following:

template<class T> struct A {
     typedef T arr[3];
};
template<class T> void f(const typename A<T>::arr) { }    // #1
template void f<int>(const A<int>::arr);                                   // #2

I added some print function declaration code before and after calling "maybe_rebuild_function_decl_type" to print out its parameter "r" which is function declaration inside "tsubst_function_decl". 
Here is the result:
a) Before calling, the function declaration is "void f(int*)" and after calling, it is adjusted to correct one as "void f(const int*)". However, after this line "SET_DECL_IMPLICIT_INSTANTIATION (r);",  it fallback to original dependent type as "void f(typename A<T>::arr) [with T = int; typename A<T>::arr = int [3]]" till end. This completely defeats the purpose of template substitution effort.  

b) On the other hand, by screening input parameter of "rebuild_function_or_method_type", I can see it is using an incorrect function type as  "void(typename A<T>::arr)" which already drops "const" prematurely.  This is due to previous #1 template function declaration parsing. So, This gives us the clear idea of the root cause of this kind of bugs. It happens during template function declaration stage #1 when producing template declarator.  Instead of doing a later-correction-effort in PR92010, my patch tries to at least avoid dropping "const" in case of "typename" and "decltype" during template function declaration stage in #1.   

Best regards,

Qingzhe Huang

From: Jason Merrill <jason@redhat.com>
Sent: September 24, 2021 3:11 PM
To: nick huang <nickhuang99@hotmail.com>; gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>
Subject: Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044] 
 
I already responded to this patch:

https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579527.html