Re: [PATCH 2/2] contrib/coccinelle: pass include paths to spatch(1)

[Patrick Steinhardt <ps@pks.im>]

On Wed, Dec 10, 2025 at 02:13:02PM +0100, Toon Claes wrote:
> In the previous commit a new coccinelle rule is added. But neiter
> `make coccicheck` nor `meson compile coccicheck` did detect a case in
> builtin/last-modified.c.
> 
> This case involves the field `scratch` in `struct last_modified`. This
> field is of type `struct bitmap` and that struct has a member
> `eword_t *words`. Both are defined in `ewah/ewok.h`. Now, while
> builtin/last-modified.c does include that header (with the subdir in the
> #include directive), it seems coccinelle does not process it. So it's
> unaware of the type of `words` in the bitmap, and it doesn't recognize
> the rule from previous commit that uses:
> 
>     type T;
>     T *ptr;
> 
> Fix coccicheck by passing all possible include paths inside the Git
> project so spatch(1) can find the headers and can determine the types.
> 
> Signed-off-by: Toon Claes <toon@iotcl.com>
> ---
>  Makefile                       | 2 +-
>  contrib/coccinelle/meson.build | 6 ++++++
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 6fc322ff88..46d07b2d52 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -981,7 +981,7 @@ SANITIZE_LEAK =
>  SANITIZE_ADDRESS =
>  
>  # For the 'coccicheck' target
> -SPATCH_INCLUDE_FLAGS = --all-includes
> +SPATCH_INCLUDE_FLAGS = --all-includes $(addprefix -I ,compat ewah refs sha256 trace2 win32 xdiff)

This feels weird to me. We never pass any of these includes to the
compiler, either. So why should Coccinelle require them?

Coming back to your example of `eword_t`, Git knows to always include
"ewah/ewok.h", and that include is relative to the root directory of Git
itself. And as the header doesn't have any includes itself, this cannot
be the root cause, either.

So I'm a bit puzzled why this patch would fix the observed issue.

Patrick