Re: Generalise the usage of exclude-list.json

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.10.2023 10:35, Luca Fancellu wrote:
> I’m sending this mail looking for feedbacks about generalising the 
> exclude-list.json, as suggested (IIRC) by Jan
> this list can be used by multiple users and not only for MISRA, by adding a 
> field to every entry.
> 
> These are the modifications I would like to do to the list, I will implement 
> them if we reach an agreement.

Looks okay to me, thanks. Just one comment on wording:

> --- a/docs/misra/exclude-list.rst
> +++ b/docs/misra/exclude-list.rst
> @@ -1,17 +1,16 @@
>  .. SPDX-License-Identifier: CC-BY-4.0
>  
> -Exclude file list for xen-analysis script
> -=========================================
> +Exclude file list for xen scripts
> +=================================
>  
> -The code analysis is performed on the Xen codebase for both MISRA
> -checkers and static analysis checkers, there are some files however that
> -needs to be removed from the findings report for various reasons (e.g.
> -they are imported from external sources, they generate too many false
> -positive results, etc.).
> +Different Xen scripts can perform operations on the codebase to check its
> +compliance for a set of rules, however Xen contains some files that are taken
> +from other projects (e.g. linux) and they can't be updated to allow 
> backporting
> +fixes from their source, for this reason the file 
> docs/misra/exclude-list.json
> +is kept as a source of all these files that are external to the Xen project.

I'd suggest s/allow/ease/ - backports are always possible, but may end up
needing to be done entirely manually when original formatting was altered.

Jan

> -For this reason the file docs/misra/exclude-list.json is used to exclude 
> every
> -entry listed in that file from the final report.
> -Currently only the cppcheck analysis will use this file.
> +Every entry of the file can be linked to different checkers, so that this 
> list
> +can be used by multiple scripts selecting only the required entries.
>  
>  Here is an example of the exclude-list.json file::
>  
> @@ -21,10 +20,12 @@ Here is an example of the exclude-list.json file::
>  |        {
>  |            "rel_path": "relative/path/from/xen/file",
>  |            "comment": "This file is originated from ..."
> +|            "checkers": "xen-analysis"
>  |        },
>  |        {
>  |            "rel_path": "relative/path/from/xen/folder/*",
>  |            "comment": "This folder is a library"
> +|            "checkers": "xen-analysis some-checker"
>  |        },
>  |        {
>  |            "rel_path": "relative/path/from/xen/mem*.c",
> @@ -39,6 +40,12 @@ Here is an explanation of the fields inside an object of 
> the "content" array:
>     match more than one file/folder at the time. This field is mandatory.
>   - comment: an optional comment to explain why the file is removed from the
>     analysis.
> + - checkers: an optional list of checkers that will exclude this entries from
> +   their results. This field is optional and when not specified, it means 
> every
> +   checker will use that entry.
> +   Current implemented values for this field are:
> +    - xen-analysis: the xen-analysis.py script exclude this entry for both 
> MISRA
> +      and static analysis scan. (Implemented only for Cppcheck tool)
>  
>  To ease the review and the modifications of the entries, they shall be 
> listed in
>  alphabetical order referring to the rel_path field.
> 
> 
> --------------------------------------------------------------------------------------------------------------------------------------
> 
> In this way I could use this list also for the clang-format tool, excluding 
> all the file from external sources
> plus the file we don’t want clang-format to touch.
> 
> Cheers,
> Luca
> 
>