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
