Re: [PATCH][14 backport] c++: Fix instantiation of imported temploid friends [PR114275]

[Jason Merrill <jason@redhat.com>]

On 5/24/24 10:40, Iain Sandoe wrote:
> 
> 
>> On 24 May 2024, at 14:54, Jason Merrill <jason@redhat.com> wrote:
>>
>> On 5/24/24 04:06, Nathaniel Shead wrote:
>>> On Thu, May 23, 2024 at 06:41:06PM -0400, Jason Merrill wrote:
>>>> On 5/13/24 07:56, Nathaniel Shead wrote:
>>>>>>> @@ -11751,9 +11767,16 @@ tsubst_friend_class (tree friend_tmpl, tree args)
>>>>>>>           if (tmpl != error_mark_node)
>>>>>>>     	{
>>>>>>>     	  /* The new TMPL is not an instantiation of anything, so we
>>>>>>> -	     forget its origins.  We don't reset CLASSTYPE_TI_TEMPLATE
>>>>>>> +	     forget its origins.  It is also not a specialization of
>>>>>>> +	     anything.  We don't reset CLASSTYPE_TI_TEMPLATE
>>>>>>>     	     for the new type because that is supposed to be the
>>>>>>>     	     corresponding template decl, i.e., TMPL.  */
>>>>>>> +	  spec_entry elt;
>>>>>>> +	  elt.tmpl = friend_tmpl;
>>>>>>> +	  elt.args = CLASSTYPE_TI_ARGS (TREE_TYPE (tmpl));
>>>>>>> +	  elt.spec = TREE_TYPE (tmpl);
>>>>>>> +	  type_specializations->remove_elt (&elt);
>>>>>>
>>>>>> For GCC 14.2 let's guard this with if (modules_p ()); for GCC 15 it can be
>>>>>> unconditional.  OK.
>>>>>
>>>>> I'm looking to backport this patch to GCC 14 now that it's been on trunk
>>>>> some time.  Here's the patch I'm aiming to add (squashed with the
>>>>> changes from r15-220-gec2365e07537e8) after cherrypicking the
>>>>> prerequisite commit r15-58-g2faf040335f9b4; is this OK?
>>>>>
>>>>> Or should I keep it as two separate commits to make the cherrypicking
>>>>> more obvious? Not entirely sure on the etiquette around this.
>>>>
>>>> It's OK to squash them, but it's typical to use -x (directly or via git
>>>> gcc-backport) to mention where a branch change was cherry-picked from, and
>>>> in this case it would make sense to edit in the second commit so it's clear
>>>> the backport includes both.  OK that way.
>>> Sorry, still a bit confused :)  Do you mean to merge the two commits
>>> together such that there are two "cherry picked from commit ..."s in the
>>> commit message?  Or just list second commit, and mention that it
>>> includes both in the commit message?
>>
>> I was thinking
>>
>> (cherry picked from commit aaaaa and bbbbb)
> 
> For the record, I do not think the git hooks with allow that exactly (or, at least, if they
> do I did not find the right syntax);  what I’ve done in similar cases is to keep the main
> “cherry picked from” line for the main patch and then add text to the intro section
> saying that xxxxxxxx and yyyyyyyy are also included.

Looks like the git_commit.py regex "cherry picked from commit 
(?P<hash>\w+)" will ignore everything after the first commit-id, so it 
should be fine.  You just can't pluralize "commit" to "commits".  :)

Jason