Re: where is PRnnnn required again?

[Martin Sebor <msebor@gmail.com>]

On 7/7/21 11:51 AM, Jakub Jelinek wrote:
> On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote:
>> I came away from the recent discussion of ChangeLogs requirements
>> with the impression that the PRnnnn bit should be in the subject
>> (first) line and also above the ChangeLog part but doesn't need
>> to be repeated again in the ChangeLog entries.  But my commit
>> below was rejected last Friday with the subsequent error.  Adding
>> PR middle-end/98871 to the ChangeLog entry let me push the change:
>>
>> https://gcc.gnu.org/g:6feb628a706e86eb3f303aff388c74bdb29e7381
>>
>> I just had the same error happen now, again with what seems like
>> a valid commit message.  Did I misunderstand something or has
>> something changed recently?
>>
>> Martin
>>
>> commit 8a6d08bb49c2b9585c2a2adbb3121f6d9347b780 (HEAD -> master)
>> Author: Martin Sebor <msebor@redhat.com>
>> Date:   Fri Jul 2 16:16:31 2021 -0600
>>
>>      Improve warning suppression for inlined functions [PR98512].
> 
> This states a PR number on the first line
>>
>>      Resolves:
>>      PR middle-end/98871 - Cannot silence -Wmaybe-uninitialized at
>> declaration si
>> te
>>      PR middle-end/98512 - #pragma GCC diagnostic ignored ineffective in
>> conjunct
>> ion with alias attribute
> 
> but these are intentionally not considered part of the ChangeLog entry,
> so it isn't specified anywhere and that is why it has been rejected.

But the PRs are used to update Bugzilla, right?  E.g., this commit:

   https://gcc.gnu.org/g:6d3bab5d5adb3e28ddb16c97b0831efdea23cf7d

updated both of:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512#c12
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871#c7

(but not ChangeLogs).  So why can't they also be used to update
the ChangeLog entries?

> 
> The ChangeLog entry must be in a rigid form so that random text in the middle
> of the commit message isn't mistaken for start of the ChangeLog entry.

If it's okay for the PR lines to be used to update Bugzilla why is
it not also okay to use them to update ChangeLogs?  Or to put it
differently: can we change the script to do both?  I can't be
the only one who finds this onerous and confusing.

Martin

> 
> contrib/gcc-changelog/git_commit.py
> has
> author_line_regex = \
>          re.compile(r'^(?P<datetime>\d{4}-\d{2}-\d{2})\ {2}(?P<name>.*  <.*>)')
> changelog_regex = re.compile(r'^(?:[fF]or +)?([a-z0-9+-/]*)ChangeLog:?')
> pr_regex = re.compile(r'\tPR (?P<component>[a-z+-]+\/)?([0-9]+)$')
> dr_regex = re.compile(r'\tDR ([0-9]+)$')
> star_prefix_regex = re.compile(r'\t\*(?P<spaces>\ *)(?P<content>.*)')
> and will consider as first line of the ChangeLog part:
>              if (changelog_regex.match(b) or self.find_changelog_location(b)
>                      or star_prefix_regex.match(b) or pr_regex.match(b)
>                      or dr_regex.match(b) or author_line_regex.match(b)
>                      or b.lower().startswith(CO_AUTHORED_BY_PREFIX)):
>                  self.changes = body[i:]
>                  return
> Once something is considered a ChangeLog part, everything after it has
> to be a valid ChangeLog entry format.
> Matching just PR component/NNNNN with random text afterwards at the start
> of line or even somewhere in the middle would trigger any time one talks about some
> PR in the description.
> 
>>
>>      gcc/ChangeLog:
>>
>>              * diagnostic.c (get_any_inlining_info): New.
>>              (update_effective_level_from_pragmas): Handle inlining context.
>>              (diagnostic_enabled): Same.
>>              (diagnostic_report_diagnostic): Same.
>>              * diagnostic.h (struct diagnostic_info): Add ctor.
>>              (struct diagnostic_context): Add new member.
>>              * tree-diagnostic.c (set_inlining_locations): New.
>>              (tree_diagnostics_defaults): Set new callback pointer.
> 
> 	Jakub
>