Re: [cocci] Iterator macros

[Julia Lawall <julia.lawall@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]



On Wed, 14 Aug 2024, Andrzej Hajda wrote:

>
>
> On 14.08.2024 09:19, Julia Lawall wrote:
> > > I guess the issue here could be a problem with parsing igt code (it is
> > > also an
> > > issue with kernel drivers using iterators).
> > > Cocci quite often does not recognize automatically iterators or other
> > > constructs, and does not scan them at all.
> > > Try run for example:
> > > $ spatch --parse-c tests/intel/gem_ctx_exec.c
> > > ...
> > > NB total files = 1; perfect = 0; pbs = 1; timeout = 0; =========> 0%
> > > nb good = 385,  nb passed = 19 =========> 3.12% passed
> > > nb good = 385,  nb bad = 204 =========> 66.45% good or passed
> > >
> > > As I understand, lines marked as "bad" are skipped during cocci pass, am I
> > > right?
> > > Some workaround is to define iterators by hand in the script or include
> > > files.
> > The following file:
> >
> > #define igt_main int main ()
> > #define igt_simple_main int main ()
> >
> > #define igt_fixture
> > #define igt_subtest_group
> > #define igt_dynamic(x) YACFE_ITERATOR
> > #define igt_dynamic_f(x) YACFE_ITERATOR
> > #define igt_subtest(x) YACFE_ITERATOR
> > #define igt_subtest_with_dynamic(x) YACFE_ITERATOR
> > #define igt_subtest_with_dynamic_f(x) YACFE_ITERATOR
> > #define igt_subtest_f(x) YACFE_ITERATOR
> > #define igt_until_timeout(x) YACFE_ITERATOR
> > #define igt_while_interruptible(x) YACFE_ITERATOR
> > #define igt_list_for_each_entry_safe_reverse(x) YACFE_ITERATOR
> > #define igt_list_for_each_entry_safe(x) YACFE_ITERATOR
> > #define igt_list_for_each_entry(x) YACFE_ITERATOR
> > #define _Atomic(x) x
> >
> > managed to parse over 98% of the lines in
> >
> > https://gitlab.freedesktop.org/drm/igt-gpu-tools
> >
> > Command line spatch --parse-c . --macro-file-builtins igt.h
> >
> > I'll check on the driver file you mentioned.  Thanks.
>
> Wow, great.
>
> I wonder if it would be possible to issue warning if spatch encounters lines
> which it is not able to parse, to avoid confusion.

The theory is that generally you don't want that, because lost of macros
will trigger warnings, but are not relevant to the change that you want to
make.

But there is an option --verbose-parsing that should provide more
information.

julia