[PATCH] D74735: [analyzer] Add support for CXXInheritedCtorInitExpr.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, rnkovacs, Szelethus, baloghadamsoftware, Charusso.
Herald added subscribers: cfe-commits, martong, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet, kristof.beyls.
Herald added a project: clang.

`CXXInheritedCtorInitExpr` shows up when code looks roughly like this:

  struct A {
    A(int x) { ... }
  };
  
  struct B {
    using A::A;  // !!
  };

The AST for the autogenerated constructor for `B` looks like this:

  `-CXXConstructorDecl implicit used A 'void (int)' inline
    |-ParmVarDecl implicit 'int'
    |-CXXCtorInitializer 'A'
    | `-CXXInheritedCtorInitExpr 'A'  // !!
    `-CompoundStmt

So far we've been dropping coverage every time we've encountered `CXXInheritedCtorInitExpr`. This patch attempts to add some support for it.

The AST is rather annoying to work with. `CXXInheritedCtorInitExpr` is not related to `CXXConstructExpr`, so it requires a new `CallEvent` sub-class in order to capture its semantics properly.

There are also no argument expressions, even though the inherited constructor for `A` takes one argument `x`. The current patch takes argument expressions from the topmost `CXXConstructExpr`, which also requires a different location context to access. As far as i can see, the result of such substitution is always correct, i.e., the resulting argument `SVal` obtained from the Environment this way will always be `evalBinOp`-equal to the correct argument value. I'm still not sure it's a great long-term solution; it might be better to outright forbid calling `getArgExpr()` and `getNumArgs()` on a `CXXInheritedConstructorCall`.

Another piece of work that needs to be done (probably in follow-up patches) is supporting argument constructors in the `CXXInheritedCtorInitExpr`; the last test shows that it's not quite working. It's also going to be very annoying because the construct-expressions for such arguments are also not present in the AST. So this is going to be yet another kind of `CallEvent`s that don't correspond to any `Expr` (the previous such case being destructors that aren't invoked manually).


Repository:
  rC Clang

https://reviews.llvm.org/D74735

Files:
  clang/include/clang/Analysis/ConstructionContext.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  clang/lib/StaticAnalyzer/Core/SymbolManager.cpp
  clang/test/Analysis/cxx-inherited-ctor-init-expr.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D74735.245013.patch
Type: text/x-patch
Size: 23564 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200217/a5d4244e/attachment-0001.bin>