[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