[cfe-dev] FW: Running ASTMatcher over main file only

Manuel Klimek klimek at google.com
Sun Oct 13 15:23:53 PDT 2013


On Sun, Oct 13, 2013 at 10:48 AM, Kirk Fertitta
<kirk at pacificmindworks.com>wrote:

>  Thanks very much Edwin.  This is the sort of insight I was looking for.
> Quite new to Clang here.  I certainly would prefer to keep it simple if I
> can, and there is some perf tolerance for my application, as what I’m
> initially doing is building a library to do some fairly basic (but
> domain-specific) roundtripping on a VC++ app.  So, there will be windows
> headers included as well as the usual suspects (MS STL, etc).  But, my
> roundtripping operations are always taking place in only a few files within
> the project.  And, the operations take place in response to user-initiated
> commands, which means as long as the UI is “responsive” enough, I can
> tolerate some extra traversal it seems.  I certainly don’t feel 100%
> comfortable hacking the source just yet to modify the RecursiveASTVisitor.
> ****
>
> ** **
>
> From a functional standpoint, should I be concerned about the matcher
> coming across something in the Windows headers it doesn’t understand (which
> I understand will certainly happen) if I’m never concerned about matching
> in those headers?  In other words, if I want to find a FunctionDecl in my
> main source file and Clang chokes on an included header, would it still
> likely find my main source file decl or is it an “all-or-nothing” deal?  I
> suppose if a type decl was in a header it didn’t understand and that type
> was used in the signature of my target function, then seemingly that would
> be a big problem.
>

If clang "chokes" on a header, chances are that the rest of the AST will be
slightly wrong, and you might miss some things as the AST doesn't look like
you'd expect it.


> ****
>
> ** **
>
> Thanks very much again for taking the time to answer Clang newbie
> questions.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Kirk Fertitta****
>
> Chief Technical Officer****
>
> Pacific MindWorks, Inc.****
>
> ph:  858-207-6198****
>
> fax: 858-521-1385****
>
> ** **
>
> *From:* Edwin Vane [mailto:revane at gmail.com <revane at gmail.com>]
> *Sent:* Saturday, October 12, 2013 5:52 AM
> *To:* Kirk Fertitta
> *Cc:* cfe-dev at cs.uiuc.edu
> *Subject:* Re: [cfe-dev] Running ASTMatcher over main file only****
>
> ** **
>
> In my experience the cost of traversing parts of the AST that come from a
> header is negligible. So if you reject matches in the callback for those
> that come from files you don't want to change that would be the best way to
> do it. If you're interested in measuring the performance difference you'd
> have to hack the internal RecursiveASTVisitor the match finding stuff uses
> and include a file test at  various nodes in the tree to prune the whole
> sub-tree. Unless your translation unit is absolutely massive and most of it
> comes from files you don't care about I can't see there being much of a
> difference.****
>
> ** **
>
> On Fri, Oct 11, 2013 at 11:50 AM, Kirk Fertitta <kirk at pacificmindworks.com>
> wrote:****
>
>  Is there a way to run a matcher directly on just the main source file
> only, as opposed to all of the includes? I know I can discriminate in my
> callback, but didn’t know if the “penalty” for traversing so much code was
> negligible or somehow avoidable.****
>
>  ****
>
> Any advice is much appreciated.****
>
>  ****
>
> Kirk Fertitta****
>
> Chief Technical Officer****
>
> Pacific MindWorks, Inc.****
>
> ph:  858-207-6198****
>
> fax: 858-521-1385****
>
>  ****
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev****
>
>
>
>
> --
> Edwin V ****
>
> _______________________________________________
> cfe-dev mailing list
> 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/20131013/36a479ed/attachment.html>


More information about the cfe-dev mailing list