================
@@ -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());
+
+ if (!MethodDecl)
+ return;
+
+ unsigned LBParamIdx = MethodDecl->getNumParams();
+ for (unsigned i = 0; i < MethodDecl->getNumParams(); i++) {
+ if (MethodDecl->getParamDecl(i)->hasAttr<LifetimeBoundAttr>()) {
+ LBParamIdx = i;
+ break;
+ }
+ }
+ if (LBParamIdx == MethodDecl->getNumParams())
+ return;
+
+ SVal RetVal = Call.getReturnValue();
+ const MemRegion *RetValRegion = RetVal.getAsRegion();
+ if (!RetValRegion)
+ return;
----------------
benedekaibas wrote:
I have switched the map key to work with `SymbolRef` as it is in the new code I
have pushed, but once I started testing it on the small code snippets I have
neither the return by value nor the return by reference case works. For both
cases when I debugged the file the null check for `RetValSymbol` fired, so both
cases end up with `getAsSymbol` returning null. Since the `MemRegion` was
working for cases where the return value was by reference I am wondering if it
would make sense to create two separate program state maps for each cases?
There might be a simpler approach that I am not aware of yet.
https://github.com/llvm/llvm-project/pull/200145
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
