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 CallEvents that don't correspond to any Expr (the previous such case being destructors that aren't invoked manually).
Perhaps the example could provide the definition of the class S too.