[cfe-dev] Visiting Implicit Code [RecursiveASTVisitor]

[Michael Han]

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.

From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Manuel Klimek
Sent: Monday, June 10, 2013 5:42 AM
To: Alexandros Tzannes
Cc: cfe-dev at cs.uiuc.edu; Vikram Sadanand Adve
Subject: Re: [cfe-dev] Visiting Implicit Code [RecursiveASTVisitor]

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

On Mon, Jun 10, 2013 at 2:41 PM, Manuel Klimek <klimek at google.com<mailto:klimek at google.com>> wrote:
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.

On Wed, Jun 5, 2013 at 7:54 PM, Alexandros Tzannes <atzannes at illinois.edu<mailto:atzannes at illinois.edu>> wrote:
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


On 05/30/2013 11:35 PM, Alexandros Tzannes wrote:
Ok I (mis)filed a bug on this :) 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?

On 05/29/2013 07:20 PM, Jordan Rose wrote:
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


On May 29, 2013, at 9:39 , Alexandros Tzannes <atzannes at illinois.edu<mailto:atzannes at illinois.edu>> wrote:
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()));
  }

---------------------------------------------------------------------

Nevertheless, dumping the AST node for the CXXMethod (operator=) reveals that a nameless parameter is properly created.

Is this behavior (of not visiting the parameters of an implicit function) by design, or a corner case that slipped through the cracks? Any advice on how to visit the parameters of implicit functions with the RecursiveASTVisitor?

Cheers!
Alex
_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

--
"Under the Illinois Freedom of Information Act (FOIA), any written
communication to or from University employees regarding University
business is a public record and may be subject to public disclosure."


_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130610/0f8584dc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: implicit-decl-types.patch
Type: application/octet-stream
Size: 1119 bytes
Desc: implicit-decl-types.patch
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130610/0f8584dc/attachment.obj>