analyzer: add get_meaning_for_state_change vfunc to fd_diagnostic in sm-fd.cc [PR106286]

Message ID CY4PR1801MB1910FCEE8DA71141850C1B34C6939@CY4PR1801MB1910.namprd18.prod.outlook.com
State New, archived
Headers
Series analyzer: add get_meaning_for_state_change vfunc to fd_diagnostic in sm-fd.cc [PR106286] |

Commit Message

Li, Pan2 via Gcc-patches July 23, 2022, 4:38 p.m. UTC
  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 <mirimmad@outlook.com>
---
 gcc/analyzer/sm-fd.cc | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
  

Comments

Li, Pan2 via Gcc-patches July 23, 2022, 5:43 p.m. UTC | #1
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 <mirimmad@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
  

Patch

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))
+      return diagnostic_event::meaning (diagnostic_event::VERB_acquire,
+                                        diagnostic_event::NOUN_resource);
+    if (change.m_new_state == m_sm.m_closed)
+      return diagnostic_event::meaning (diagnostic_event::VERB_release,
+                                        diagnostic_event::NOUN_resource);
+    return diagnostic_event::meaning ();
+  }
+
 protected:
   const fd_state_machine &m_sm;
   tree m_arg;