On Sat, 2022-07-23 at 22:08 +0530, Immad Mir wrote:
> This patch adds get_meaning_for_state_change vfunc to
> fd_diagnostic in sm-fd.cc which could be used by SARIF output.
> 
> Lightly tested in x86_64 Linux.
> 
> gcc/analyzer/ChangeLog:
>         PR analyzer/106286
>         * sm-fd.cc:
>         (fd_diagnostic::get_meaning_for_state_change): New.
> 
> Signed-off-by: Immad Mir <mirim...@outlook.com>
> ---
>  gcc/analyzer/sm-fd.cc | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
> index c3dac48509e..f77b1f4d3e2 100644
> --- a/gcc/analyzer/sm-fd.cc
> +++ b/gcc/analyzer/sm-fd.cc
> @@ -229,6 +229,22 @@ public:
>      return label_text ();
>    }
>  
> +  diagnostic_event::meaning
> +  get_meaning_for_state_change (
> +      const evdesc::state_change &change) const final override
> +  {
> +    if (change.m_old_state == m_sm.get_start_state ()
> +            && (change.m_new_state == m_sm.m_unchecked_read_write
> +        || change.m_new_state == m_sm.m_unchecked_read_only
> +        || change.m_new_state == m_sm.m_unchecked_write_only))

I think you can simplify this by using:

   m_sm.is_unchecked_fd_p (change.m_new_state)

for the right-hand side of the &&.


[...snip...]

Other than that, patch looks OK, but please add a test case for this
e.g. "fd-meaning.c"; see:

  gcc/testsuite/gcc.dg/analyzer/file-meaning-1.c

for an analogous one for the sm-file.cc (since otherwise it's too easy
for this kind of thing to regress).

Dave

Reply via email to