From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Derrick Stolee <derrickstolee@github.com>,
Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] ci: update 'static-analysis' to Ubuntu 22.04
Date: Fri, 26 Aug 2022 03:48:15 -0400 [thread overview]
Message-ID: <Ywh6v8oo3nRl/O5h@coredump.intra.peff.net> (raw)
In-Reply-To: <220825.86ilmg4mil.gmgdl@evledraar.gmail.com>
On Thu, Aug 25, 2022 at 12:47:53PM +0200, Ævar Arnfjörð Bjarmason wrote:
> What's happening here is that coccinelle can no longer properly parse
> the file after the UNUSED() macros were applied to refs.c.
Ugh. Thanks for finding this.
I'm a little disappointed in coccinelle here. I mean, I get that it
probably can't just use the output of "gcc -E"; it wants to see and
transform the code as written (and maybe even translate macros). But
if it doesn't understand the macros enough to see inside them, there are
a lot of things it is going to get confused by.
A simple example like this shows that it doesn't really see inside them:
$ cat foo.c
#define foo(x) bar(x)
static void fun(int x) { foo(x); }
$ cat foo.cocci
expression E;
@@
- bar(E);
+ changed(E);
I wonder what it makes of code-generation macros like
for_each_string_list_item(). Or all of commit-slab.
Likewise, the manner in which it fails is unexpected. I could see it
getting confused about the line in question, but why would that cause it
to fail to see the of a strbuf in another function entirely?
I realize that pseudo-parsing C is an incredibly hard problem. But I
also wonder how robust the tool actually is in practice. We've had a lot
of mystery "now why didn't it catch this case" incidents over the years.
Just running the tip of master with --verbose-parsing yields quite a few
"bad" and "parse error" entries in the log. I wonder how much that
contributes.
> We should probably coerce coccinelle into stopping in general if it's
> encountering "BAD:!!!!!" parse errors behind the scenes, as it clearly
> results in broken logic, but offhand (and from briefly browsing the
> manpage) I don't know a way to do that.
You could detect the BAD entries from the log and complain before
returning the exit code to make. But since there are several instances
already, I suspect it's a losing battle. We need some way to actually
_fix_ them. And in the meantime, it does seem to _mostly_ work, as it
clearly has some kind of resync logic.
> But the fix here isn't to delete unused.cocci, but to hold off on the
> UNUSEwork D() patches until we figure out how to make coccinelle jive with
> them.
Yeah, my general skepticism and disappointment above notwithstanding,
this seems like the best path forward from here. I tried a few other
tricks (like --macro-file and --iso-file), but if its parser chokes, I
don't think there's much we can do about it. Even if we wrote a patch to
coccinelle itself (and I have no interest in doing that myself), it
would take a while to become available.
-Peff
next prev parent reply other threads:[~2022-08-26 7:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 17:28 [PATCH] ci: update 'static-analysis' to Ubuntu 22.04 Derrick Stolee via GitGitGadget
2022-08-24 14:40 ` Johannes Schindelin
2022-08-24 19:59 ` Junio C Hamano
2022-08-24 23:43 ` Junio C Hamano
2022-08-25 0:30 ` Derrick Stolee
2022-08-25 4:43 ` Junio C Hamano
2022-08-25 10:47 ` Ævar Arnfjörð Bjarmason
2022-08-25 16:08 ` Junio C Hamano
2022-08-25 17:09 ` [PATCH 0/2] git-compat-util.h: change UNUSED(var) to UNUSED Ævar Arnfjörð Bjarmason
2022-08-25 17:09 ` [PATCH 1/2] git-compat-util.h: use "UNUSED", not "UNUSED(var)" Ævar Arnfjörð Bjarmason
2022-08-25 17:09 ` [PATCH 2/2] git-compat-util.h: use "deprecated" for UNUSED variables Ævar Arnfjörð Bjarmason
2022-08-26 7:52 ` [PATCH 0/2] git-compat-util.h: change UNUSED(var) to UNUSED Jeff King
2022-08-26 7:48 ` Jeff King [this message]
2022-08-26 16:46 ` [PATCH] ci: update 'static-analysis' to Ubuntu 22.04 Junio C Hamano
2022-08-27 12:58 ` Jeff King
2022-08-29 5:56 ` Junio C Hamano
2022-08-29 10:29 ` Ævar Arnfjörð Bjarmason
2022-08-31 15:12 ` Jeff King
2022-08-31 8:44 ` SZEDER Gábor
2022-08-31 12:13 ` Ævar Arnfjörð Bjarmason
2022-08-31 15:24 ` Jeff King
2022-08-31 19:19 ` Junio C Hamano
2022-08-31 18:05 ` SZEDER Gábor
2022-08-31 19:29 ` Ævar Arnfjörð Bjarmason
2022-08-25 14:57 ` Ævar Arnfjörð Bjarmason
2022-08-25 16:17 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ywh6v8oo3nRl/O5h@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).