public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [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, PR102
@ 2021-10-03 11:14 Nick Huang
  2021-10-03 20:16 ` Nick Huang
  2021-10-07 20:50 ` [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,PR102 Jason Merrill
  0 siblings, 2 replies; 6+ messages in thread
From: Nick Huang @ 2021-10-03 11:14 UTC (permalink / raw)
  To: Gcc-patches, Jason Merrill

Hi Jason,

I made a little improvement of my fix by including template
type parameter to not dropping cv-const because they are similar to dependent
type which you cannot determine whether they are top-level cv-qualifier or not
until instantiation.

+         if (processing_template_decl
+               && (TREE_CODE (type) == TYPENAME_TYPE
+                  || TREE_CODE (type) == DECLTYPE_TYPE
++                  || TREE_CODE (type) == TEMPLATE_TYPE_PARM  // this is new
+                  )
+            )

1. It fix your test case of
template <class T>
struct A{
   void f(T);
};
template <class T>
void A<T>::f(const T){ }
template<>
void A<int[]>::f(const int*){}

current GCC mistakenly accepts without considering the gap of missing "const"
between declaration and out of line definition. clang correctly rejects it.
(https://www.godbolt.org/z/qb9Tf99eK) and explains the cause nicely.
My fix also rejects it.

2. It also fix a more obvious core1001 issue of free function as my previous fix
only deals with typename/decltype cases.
template<class T>
void f(const T){}
template<>
void f<int[3]>(const int*){}

Your comment is appreciated.

thank you

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [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, PR102
@ 2021-10-08 20:19 Nick Huang
  2021-10-14 11:04 ` Nick Huang
  0 siblings, 1 reply; 6+ messages in thread
From: Nick Huang @ 2021-10-08 20:19 UTC (permalink / raw)
  To: Gcc-patches, Jason Merrill

First of all, I am sorry for my late response as I missed your email.
I need to update my filter setup of gmail after switching from hotmail.

>I think WILDCARD_TYPE_P is what you want, except...
I will try this one.

>Your patch rejects that testcase even without the specialization on
>int[], which no other compiler I'm aware of does;

Honestly I now realize this is a wakeup call for me as I have been
trying to revert PR92010 approach for months as I at that time favor
the early syntax-checking approach which is considered efficient. Now
your testcase reveals me a realist practice that almost all compilers
tolerate this seemingly user's definition error because:
a) It actually follows the principle that template without instantiation
might not give error.
b) "const T" and "T" maybe turn out to be the same after instantiation
as function parameter.
So, I guess this is the real practical approach for most compilers to
rebuild function signature from declaration only when instantiation.
My approach stucks when GCC search declaration for definition because
"T" and "const T" are two different CANONICAL types. So, I now guess
that is why declarator deliberately drops cv-qualifers to tolerate your
testcase.

>You seem to have missed my September 28 mail that argued for fixing the
>bug in determine_specialization that was preventing the 92010 fix from
>handling these cases.

I did try to see this approach, but I was stuck in a sidelined issue of
PR102624 which relates to lambda-in-unevaluated-context. The point is
that I thought PR92010 starts to satisfy this pt.c:tsubst_default_argument:
gcc_assert (same_type_ignoring_top_level_qualifiers_p (type, parmtype));

But I think after introduction of lambda in unevaluated context, this may
not be correct assertion. I could be wrong on this. However, i.e.

template <class T>
void spam(decltype([]{})* ptr=nullptr)
{ }
void foo(){
  spam<int>();
}

When rebuilding lambda type from declaration, it is always a unique
different type. So, that is the reason I thought this rebuild function
type approach is imperfect. In other words,  it is no good to rebuild
function type to satisfy this may-not-be-correct-assertion,

Anyway, I now think PR92010 is practically a good approach and I will
start testing your patch.

Best regards,

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-10-15 21:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-03 11:14 [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, PR102 Nick Huang
2021-10-03 20:16 ` Nick Huang
2021-10-07 20:50 ` [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,PR102 Jason Merrill
2021-10-08 20:19 [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, PR102 Nick Huang
2021-10-14 11:04 ` Nick Huang
2021-10-15 21:00   ` [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,PR102 Jason Merrill

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).