From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 2E3243851C0B for ; Wed, 7 Jul 2021 17:53:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E3243851C0B Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-432-x4fM9x7TP-mkczRPeycsRQ-1; Wed, 07 Jul 2021 13:53:50 -0400 X-MC-Unique: x4fM9x7TP-mkczRPeycsRQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AB010802C80; Wed, 7 Jul 2021 17:53:48 +0000 (UTC) Received: from iPadvonndlhumer (ovpn-113-144.ams2.redhat.com [10.36.113.144]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3AF6360843; Wed, 7 Jul 2021 17:53:47 +0000 (UTC) Received: from iPadvonndlhumer (localhost [127.0.0.1]) by iPadvonndlhumer (8.15.2/8.15.2) with ESMTPS id 167HriDW049956 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 7 Jul 2021 19:53:44 +0200 Received: (from jakub@localhost) by iPadvonndlhumer (8.15.2/8.15.2/Submit) id 167HqhTh049734; Wed, 7 Jul 2021 19:52:43 +0200 X-Authentication-Warning: iPadvonndlhumer: jakub set sender to jakub@redhat.com using -f Date: Wed, 7 Jul 2021 19:51:42 +0200 From: Jakub Jelinek To: Martin Sebor Cc: gcc mailing list Subject: Re: where is PRnnnn required again? Message-ID: <20210707175142.GB39218@iPadvonndlhumer> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 17:53:54 -0000 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 > 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. 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. contrib/gcc-changelog/git_commit.py has author_line_regex = \ re.compile(r'^(?P\d{4}-\d{2}-\d{2})\ {2}(?P.* <.*>)') changelog_regex = re.compile(r'^(?:[fF]or +)?([a-z0-9+-/]*)ChangeLog:?') pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$') dr_regex = re.compile(r'\tDR ([0-9]+)$') star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)') 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