[PATCH] D153017: [analyzer] Fix false negative when using a nullable parameter directly without binding to a variable
Balázs Benics via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Jun 15 08:58:47 PDT 2023
steakhal added inline comments.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp:569-594
+void NullabilityChecker::checkBeginFunction(CheckerContext &C) const {
+ const LocationContext *LCtx = C.getLocationContext();
+ auto AbstractCall = AnyCall::forDecl(LCtx->getDecl());
+ if (!AbstractCall)
+ return;
+
+ ProgramStateRef State = C.getState();
----------------
steakhal wrote:
> steakhal wrote:
> > Uh, the diffing here looks terrible.
> > What you probably want: Fold the `State`s, and if you are done, transition - but only if we have any parameters.
> > We need to have a single `addTransition()` call if we want a single execution path modeled in the graph. We probably don't want one path on which the first parameter's annotation is known; and a separate one where only the second, etc.
> Shouldn't we only do this for the analysis entrypoints only? (aka. top-level functions)
> I assume this checker already did some modeling of the attributes, hence we have the warnings in the tests.
Please note that each iteration of the loop will overwrite the state you made in the previous iteration this way.
Its most likely not what you want.
Because C.getState() will always return the same state no matter the context here.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D153017/new/
https://reviews.llvm.org/D153017
More information about the cfe-commits
mailing list