[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling
Balogh, Ádám via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Apr 28 00:29:44 PDT 2020
baloghadamsoftware added a comment.
In D77229#2007038 <https://reviews.llvm.org/D77229#2007038>, @baloghadamsoftware wrote:
> As I wrote, I debugged and analyzed it and I am facing a problem for which I need help. Operator calls are very poorly implemented in the AST.
Yes, indeed very poorly. A C++ operator call is either implemented as `CXXOperatorCall` or `CXXMethodCall` randomly. In the former case the `this` parameter is explicit at the beginning, in the latter case it is implicit. I managed to solve it using this piece of code:
const auto *Call = cast<Expr>(CallSite);
unsigned Index = PVD->getFunctionScopeIndex();
// For `CallExpr` of C++ member operators we must shift the index by 1
if (isa<CXXOperatorCallExpr>(Call)) {
if (const auto *CMD = dyn_cast<CXXMethodDecl>(SFC->getDecl())) {
if (CMD->isOverloadedOperator())
++Index;
}
}
But this is not the only problem with indices. I have no solution for the following call (is it really a call?) resulting in an assertion because overindexing in `nullability.mm`:
Dummy *_Nonnull (^myblock)(void) = ^Dummy *_Nonnull(void) {
Even if I try to get the `FunctionDecl` it still says that it has `0` parameters, exactly what `CallExpr` says, but we //have// a parameter here with index of `0`. How can it be? How should I handle this strange case? I only have very basic //Objective-C// knowledge.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D77229/new/
https://reviews.llvm.org/D77229
More information about the cfe-commits
mailing list