Fixes #55347
Builtin functions (such ast std::move, std::forward, std::as_const) have a body generated during the analysis not related to any source file so their statements have no valid source locations.
ReturnPtrRange checker should not report issues for these builtin functions because they only forward its parameter and do not create any new pointers.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I already reviewed this internally. For me, it looks great.
@arseniy-sonar consider adding the Fixes #55347 marker to the summary, so the commit will auto-reference the fixed issue.
Also mention the commit author sign to which we should accredit this revision if accepted.
LGTM, thanks!
This patch seems obvious but please upload with context next time (https://llvm.org/docs/Phabricator.html#phabricator-request-review-web).
clang/lib/StaticAnalyzer/Checkers/ReturnPointerRangeChecker.cpp | ||
---|---|---|
48 | I suspect that you might run into more similar problems with functions coming from "body farms". A direct check like RetE->getBeginLoc().isValid() might be more reliable. You might need to check the entire range though. We probably need a unified solution for such checks, because many checkers end up implementing them. |
clang/lib/StaticAnalyzer/Checkers/ReturnPointerRangeChecker.cpp | ||
---|---|---|
48 | We were actually considering it. We decided against it to keep the impact of this fix minimal. That being said, I wonder if a similar check should be at some higher level API, lets say inside the emitReport. |
I think we should backport this to release/16.x.
Here is the ticket for it: https://github.com/llvm/llvm-project/issues/61115
I suspect that you might run into more similar problems with functions coming from "body farms". A direct check like
might be more reliable.
You might need to check the entire range though. We probably need a unified solution for such checks, because many checkers end up implementing them.