git-commit-vandalism/contrib/coccinelle
Ævar Arnfjörð Bjarmason f7ff6597a7 cocci: add a "coccicheck-test" target and test *.cocci rules
Add a "coccicheck-test" target to test our *.cocci rules, and as a
demonstration add tests for the rules added in 39ea59a257 (remove
unnecessary NULL check before free(3), 2016-10-08) and
1b83d1251e (coccinelle: add a rule to make "expression" code use
FREE_AND_NULL(), 2017-06-15).

I considered making use of the "spatch --test" option, and the choice
of a "tests" over a "t" directory is to make these tests compatible
with such a future change.

Unfortunately "spatch --test" doesn't return meaningful exit codes,
AFAICT you need to "grep" its output to see if the *.res is what you
expect. There's "--test-okfailed", but I didn't find a way to sensibly
integrate those (it relies on some in-between status files, but
doesn't help with the status codes).

Instead let's use a "--sp-file" pattern similar to the main
"coccicheck" rule, with the difference that we use and compare the
two *.res files with cmp(1).

The --very-quiet and --no-show-diff options ensure that we don't need
to pipe stdout and stderr somewhere. Unlike the "%.cocci.patch" rule
we're not using the diff.

The "cmp || git diff" is optimistically giving us better output on
failure, but even if we only have POSIX cmp and no system git
installed we'll still fail with the "cmp", just with an error message
that isn't as friendly. The "2>/dev/null" is in case we don't have a
"git" installed.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-06 12:24:43 -07:00
..
tests cocci: add a "coccicheck-test" target and test *.cocci rules 2022-07-06 12:24:43 -07:00
.gitignore gitignore: ignore output files of coccicheck make target 2016-09-27 14:02:19 -07:00
array.cocci cocci: allow xcalloc(1, size) 2021-03-15 17:56:07 -07:00
commit.cocci commit: move members graph_pos, generation to a slab 2020-06-17 14:37:30 -07:00
equals-null.cocci contrib/coccinnelle: add equals-null.cocci 2022-05-02 09:47:55 -07:00
flex_alloc.cocci cocci: FLEX_ALLOC_MEM to FLEX_ALLOC_STR 2019-04-04 18:22:30 +09:00
free.cocci cocci: add and apply free_commit_list() rules 2022-04-13 23:56:08 -07:00
hashmap.cocci coccicheck: detect hashmap_entry.hash assignment 2019-10-07 10:20:09 +09:00
object_id.cocci cocci: retire is_null_sha1() rule 2022-06-07 15:53:24 -07:00
preincr.cocci cocci: simplify "if (++u > 1)" to "if (u++)" 2018-10-24 10:10:10 +09:00
qsort.cocci remove unnecessary check before QSORT 2016-09-29 15:42:18 -07:00
README coccicheck: introduce 'pending' semantic patches 2018-11-14 11:22:36 +09:00
strbuf.cocci cocci: allow padding with strbuf_addf() 2022-03-23 11:38:40 -07:00
swap.cocci add SWAP macro 2017-01-30 14:07:45 -08:00
the_repository.pending.cocci object-store.h: remove unused has_sha1_file*() 2022-04-01 10:16:10 -07:00
xcalloc.cocci fix xcalloc() argument order 2021-03-08 09:45:04 -08:00
xopen.cocci index-pack: use xopen in init_thread 2021-09-10 14:22:50 -07:00
xstrdup_or_null.cocci cocci: drop bogus xstrdup_or_null() rule 2022-04-30 22:23:11 -07:00

This directory provides examples of Coccinelle (http://coccinelle.lip6.fr/)
semantic patches that might be useful to developers.

There are two types of semantic patches:

 * Using the semantic transformation to check for bad patterns in the code;
   The target 'make coccicheck' is designed to check for these patterns and
   it is expected that any resulting patch indicates a regression.
   The patches resulting from 'make coccicheck' are small and infrequent,
   so once they are found, they can be sent to the mailing list as per usual.

   Example for introducing new patterns:
   67947c34ae (convert "hashcmp() != 0" to "!hasheq()", 2018-08-28)
   b84c783882 (fsck: s/++i > 1/i++/, 2018-10-24)

   Example of fixes using this approach:
   248f66ed8e (run-command: use strbuf_addstr() for adding a string to
               a strbuf, 2018-03-25)
   f919ffebed (Use MOVE_ARRAY, 2018-01-22)

   These types of semantic patches are usually part of testing, c.f.
   0860a7641b (travis-ci: fail if Coccinelle static analysis found something
               to transform, 2018-07-23)

 * Using semantic transformations in large scale refactorings throughout
   the code base.

   When applying the semantic patch into a real patch, sending it to the
   mailing list in the usual way, such a patch would be expected to have a
   lot of textual and semantic conflicts as such large scale refactorings
   change function signatures that are used widely in the code base.
   A textual conflict would arise if surrounding code near any call of such
   function changes. A semantic conflict arises when other patch series in
   flight introduce calls to such functions.

   So to aid these large scale refactorings, semantic patches can be used.
   However we do not want to store them in the same place as the checks for
   bad patterns, as then automated builds would fail.
   That is why semantic patches 'contrib/coccinelle/*.pending.cocci'
   are ignored for checks, and can be applied using 'make coccicheck-pending'.

   This allows to expose plans of pending large scale refactorings without
   impacting the bad pattern checks.