Visiting Implicit Code [RecursiveASTVisitor]

Hi,
I'm writing a checker that needs to visit and understand implicit code (among other things).

Note: All three "should" functions of my visitor return true, though I'm not sure this matters in this specific case (keep reading).
   bool shouldVisitTemplateInstantiations() const { return true; }
   bool shouldVisitImplicitCode() const { return true; }
   bool shouldWalkTypesOfTypeLocs() const { return true; }

In the code below the operator= is implicit (see commented out code)

class Data {
public:
   int x;
   int y;

//inline Data &operator=(const Data &D) noexcept {
// this->x = D.x;
// this->y = D.y;
// return *this;
//}

};

void copy(Data in, Data out) {
   out = in;
}

I'm visiting the code using the RecursiveASTVisitor and my problem is that the parameter of the implicit function is not visited because getTypeSourceInfo() returns null on line 1739 of RecursiveASTVisitor.h

-- RecursiveASTVisitor.h:lines 1735-1741 ----------------------------

   // Visit the function type itself, which can be either
   // FunctionNoProtoType or FunctionProtoType, or a typedef. This
   // also covers the return type and the function parameters,
   // including exception specifications.
   if (TypeSourceInfo *TSI = D->getTypeSourceInfo()) {
     TRY_TO(TraverseTypeLoc(TSI->getTypeLoc()));
   }

Sounds like a mistake—there are plenty of legitimate reasons to traverse the params of an implicit function. Please file a bug at http://llvm.org/bugs/.

Jordan

Ok I (mis)filed a bug on this :slight_smile: Thanks for refiling it.

Now, if I were to try and fix this bug, where would I start? More specifically, is getTypeSourceInfo() supposed to return null for implicit function declarations? Probably not, right?

Hi all,
I am interesting in fixing this bug, unless someone is already working on it, but I may need some help as I am not familiar with the parser side of the Frontend in clang. Does anyone have any suggestions or advice on my question below?

Thanks in advance
Alex

The easiest way to get an answer is probably to hang out on #llvm on oftc and try to get a hold of zygoloid or dgregor.

(or alternatively, hack up a patch that fixes the problem, together with nice tests, and send it to cfe-commits)

I think the problem is when declaring implicit copy assignment the TypeSourceInfo for the copy assignment method declaration is set to 0 but RAV relies on it to traverse the parameter variable declaration inside the copy assignment function.

Attach a work in progress patch here. I am not sure if this is the right way of building the type nodes for implicit copy assignment as it feels hacky (and it introduces two regressions). For explicit declared functions the type nodes are built through GetFullTypeForDeclarator() but that is not reusable in this case.

Is there any better approach to build the type nodes for implicit declared functions?

Michael.

implicit-decl-types.patch (1.09 KB)