================
@@ -0,0 +1,73 @@
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include <AllocationState.h>
+
+using namespace clang;
+using namespace ento;
+
+REGISTER_MAP_WITH_PROGRAMSTATE(LifetimeBoundMap, const MemRegion *,
+ const MemRegion *);
+
+class LifetimeAnnotations : public Checker<check::PostCall> {
+public:
+ void checkPostCall(const CallEvent &Call, CheckerContext &C) const;
+ void printState(raw_ostream &Out, ProgramStateRef State, const char *NL,
+ const char *Sep) const override;
+};
+
+void LifetimeAnnotations::checkPostCall(const CallEvent &Call,
+ CheckerContext &C) const {
+ ProgramStateRef State = C.getState();
+
+ const auto *MethodDecl = dyn_cast_if_present<CXXMethodDecl>(Call.getDecl());
----------------
benedekaibas wrote:
Thank you! Actually I have started moving to this direction in this morning
since I saw how InnerPointer uses `AnyFunctionCall`. Rewriting the declaration
detection to work with `AnyFunctionCall` would be the right move then? The name
suggests for me that it represents all the function calls present in the
program, but I am not sure if that's actually the case. The documentation says:
`Represents a call to any sort of function that might have a FunctionDecl`.
If `AnyFunctionCall` does what its name suggests then I am also wondering if it
gives the `FunctionDecls` scope you mentioned? Then it would make perfect sense
to implement `checkPostCall` that way.
https://github.com/llvm/llvm-project/pull/200145
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
