Skip to content

[clang][StaticAnalyzer] fix function evalCall() typo in CheckerDocumentation #83677

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

mzyKi
Copy link
Contributor

@mzyKi mzyKi commented Mar 2, 2024

bool evalCall(const CallEvent &Call, CheckerContext &C) is corret form.

@llvmbot llvmbot added clang Clang issues not falling into any other category clang:static analyzer labels Mar 2, 2024
@llvmbot
Copy link
Member

llvmbot commented Mar 2, 2024

@llvm/pr-subscribers-clang

Author: Exile (mzyKi)

Changes

bool evalCall(const CallEvent &Call, CheckerContext &C) is corret form.


Full diff: https://github.com/llvm/llvm-project/pull/83677.diff

1 Files Affected:

  • (modified) clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp (+1-1)
diff --git a/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp b/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp
index 3e5e2b9139149d..0ca0c487b64550 100644
--- a/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp
@@ -226,7 +226,7 @@ class CheckerDocumentation : public Checker< check::PreStmt<ReturnStmt>,
   /// first one wins.
   ///
   /// eval::Call
-  bool evalCall(const CallExpr *CE, CheckerContext &C) const { return true; }
+  bool evalCall(const CallEvent &Call, CheckerContext &C) const { return true; }
 
   /// Handles assumptions on symbolic values.
   ///

@llvmbot
Copy link
Member

llvmbot commented Mar 2, 2024

@llvm/pr-subscribers-clang-static-analyzer-1

Author: Exile (mzyKi)

Changes

bool evalCall(const CallEvent &amp;Call, CheckerContext &amp;C) is corret form.


Full diff: https://github.com/llvm/llvm-project/pull/83677.diff

1 Files Affected:

  • (modified) clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp (+1-1)
diff --git a/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp b/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp
index 3e5e2b9139149d..0ca0c487b64550 100644
--- a/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp
@@ -226,7 +226,7 @@ class CheckerDocumentation : public Checker< check::PreStmt<ReturnStmt>,
   /// first one wins.
   ///
   /// eval::Call
-  bool evalCall(const CallExpr *CE, CheckerContext &C) const { return true; }
+  bool evalCall(const CallEvent &Call, CheckerContext &C) const { return true; }
 
   /// Handles assumptions on symbolic values.
   ///

@steakhal
Copy link
Contributor

steakhal commented Mar 2, 2024

Makes sense, but how did it build before the fix?
I thought by inheriting from Checker it would take the address of the member function with the expected signature to store them inside vectors. How could it take the address of a nonexisting member function?

@mzyKi
Copy link
Contributor Author

mzyKi commented Mar 3, 2024

Makes sense, but how did it build before the fix? I thought by inheriting from Checker it would take the address of the member function with the expected signature to store them inside vectors. How could it take the address of a nonexisting member function?
I think evalCall() is an independent function in CheckerDocumentation.cpp and it has no relation with Checker<eval::Call>. If no problem, I will merge soon.

@mzyKi mzyKi merged commit 8715f25 into llvm:main Mar 4, 2024
steakhal added a commit that referenced this pull request Mar 5, 2024
… checker callbacks (#83973)

In PR #83677 I was surprised to see that outdated checker callback
signatures are a problem. It turns out, we need the `registerChecker...`
function to invoke the `Mgr.registerChecker<>()` which would instantiate
the `_register` calls, that would take the address of the defined
checker callbacks. Consequently, if the expected signatures mismatch, it
won't compile from now on, so we have static guarantee that this issue
never pops up again.

Given we need the `register` call, at this point we could just hook this
checker into the `debug` package and make it never registered. It
shouldn't hurt anyone :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:static analyzer clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants