On Fri, 2020-08-14 at 09:26 +0200, Martin Liška wrote:
> On 8/14/20 9:22 AM, Martin Liška wrote:
> > On 8/13/20 10:58 PM, David Malcolm via Gcc-patches wrote:
> > > PR analyzer/93032 (missing leak diagnostic for
> > > zlib/contrib/minizip/mztools.c)
> > > PR analyzer/93938 (ICE in analyzer)
> > > PR analyzer/94011 (ICE in analyzer)
> > > PR analyzer/94099 (ICE in analyzer)
> > > PR analyzer/94399 (leak false positive with
> > > __attribute__((cleanup())))
> > > PR analyzer/94458 (leak false positive)
> > > PR analyzer/94503 (ICE on C++ return-value-optimization)
> > > PR analyzer/94640 (leak false positive)
> > > PR analyzer/94688 (ICE in analyzer)
> > > PR analyzer/94689 ("arrays of functions are not meaningful"
> > > error)
> > > PR analyzer/94839 (leak false positive)
> > > PR analyzer/95026 (leak false positive)
> > > PR analyzer/95042 (ICE merging const and non-const C++ object
> > > instances)
> > > PR analyzer/95240 (leak false positive)
> >
> > Hello David.
> >
> > Unfortunately, this format is not recognized by gcc-changelog
> > script and
> > so the corresponding PR entries were not added to the generated
> > ChangeLog
> > entries. The currently supported regex is:
> >
> > pr_regex = re.compile(r'\tPR (?P<component>[a-z+-]+\/)?([0-9]+)$')
> >
> > which prevents parsing an entries not being standalone.
> > Anyway, I updated gcc/analyzer/ChangeLog manually.
> >
> > Thanks,
> > Martin
BTW, the entries you quoted above (with their per-bug descriptions) are
in the leading text of the commit message, without indentation, and
they are also in the section labeled "gcc/analyzer/ChangeLog with TAB
indentation, and without descriptions.
In my initial attempts to push the patch, the latter had the same text
as the former, each line indented with a tab, and it caused the commit
to fail the push hook.
I removed the trailing descriptive text from each
(TAB)PR analyzer/NNNNN
line in the ChangeLog part of the message, and the hook passed and let
me push the patch.
(I wanted to quote the logs here, but I don't seem to have them
anymore, sadly)
> ... and I bet for similar reasons gcc-bugs emails were not send to
> various PRs
> mentioned in the commit.
I wondered about that too. Given that the hook rejected it, and then
accepted the revised version, my theory is that the commit exceeded
some size limit for the bugzilla integration (the "git show --no-patch"
blurb and ChangeLog from the commit is 1652 lines long and approaching
100k [1])
Looking at the "Daily bump." commit
b3cb56060bcdc1cf4d38aa30b5017b802822f8c0 I see that the ChangeLog
entries did make it into the various ChangeLog files.
Dave
[1] writing the ChangeLog took about 3 days, which part of me resents
as tedious busywork, but I did find and fix several bugs whilst doing
it, including one serious one-liner mistake that was significantly
slowed down the code, so there is some merit in poring over a
candidate change line-by-line, I guess.
