This is right up your alley:<div><a href="http://llvm.org/devmtg/2011-11/#talk2">http://llvm.org/devmtg/2011-11/#talk2</a></div><div>video: <a href="http://llvm.org/devmtg/2011-11/videos/Carruth_ClangMapReduce-desktop.mp4">http://llvm.org/devmtg/2011-11/videos/Carruth_ClangMapReduce-desktop.mp4</a></div>
<div><br><div class="gmail_quote">On Tue, Feb 28, 2012 at 11:37 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
clang should support much of what you ask for.<br>
<br>
DXR ( <a href="https://wiki.mozilla.org/DXR" target="_blank">https://wiki.mozilla.org/DXR</a> ) is an existing attempt to use<br>
clang to build a program database. <a href="https://github.com/nico/complete" target="_blank">https://github.com/nico/complete</a> is<br>
some old hack from me that does the same in worse - but since there's<br>
a lot less code, maybe it's easier for a first look (relevant file:<br>
<a href="https://github.com/nico/complete/blob/master/server/complete_plugin.cc" target="_blank">https://github.com/nico/complete/blob/master/server/complete_plugin.cc</a>).<br>
<span class="HOEnZb"><font color="#888888"><br>
Nico<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Feb 28, 2012 at 8:29 PM, James K. Lowden<br>
<<a href="mailto:jklowden@schemamania.org">jklowden@schemamania.org</a>> wrote:<br>
> The "open clang projects" page refers to some potential uses of clang<br>
> for tool-building.  A few of them require metadata from the<br>
> lexer or parser.<br>
><br>
> I'm interested in creating a framework for searching and reporting on<br>
> large C++ code trees.  I wonder what work has already been done, and if<br>
> the information I want is currently available from the clang front<br>
> end.  I would begin by capturing the token metadata in SQLite, thereby<br>
> making them accessible to a variety of applications.<br>
><br>
>        Motivation<br>
><br>
> Back when the VAX dinosaur was knee-high to a mammal, I used DEC's<br>
> Source Code Analyzer (SCA)[1].  To this day, I have never seen or heard<br>
> of anything as good.  ISTM clang could be used to create something<br>
> better.<br>
><br>
> What is "as good", and what would be better?<br>
><br>
> SCA let the user:<br>
><br>
> 1.  analyze arbitrary subsets of a source code tree<br>
> 2.  dynamically restrict the range of queries on that subset<br>
> 3.  distinguish among read, write, invoke, reference, and dereference<br>
> 4.  define  "interesting" cases for repeated use, including reports<br>
><br>
>        Current Tools Fail<br>
><br>
> Microsoft's tool lacks all these features.  cscope has some of them,<br>
> but only for C.  (For example, cscope cannot search for a<br>
> destructor or anything with a scope operator.)  VS parses C++, but the<br>
> user cannot search for uses of e.g. operator<<.<br>
><br>
> The free tools I've looked at share don't really parse C++.   They<br>
> parse the nonlanguage "C/C++".  Consequently they cannot hope to<br>
> answer #3 above; they can't even distinguish between ::B and A::B.<br>
> They also lack any kind of scripting language, preventing #4 and<br>
> severely restricting the capability of #2.<br>
><br>
> These problems are all answered by clang+SQL.  Or, might be, if clang<br>
> is up to the job.<br>
><br>
>        Required Metadata<br>
><br>
> I'm sure the following is incomplete and that it is more<br>
> comprehensive than what is available from any existing tool at any<br>
> price.  Is it covered by clang at present?<br>
><br>
> [spec]<br>
><br>
> For any token<br>
><br>
> 1.  namespace<br>
> 2.  enclosing class/struct<br>
> 3.  const, static<br>
> 4.  linkage<br>
> 5.  public, protected, or private (or none)<br>
> 6.  declare, define, or use<br>
> 7.  translation unit (file) and line number<br>
><br>
> It should be possible to say in which lines of a file a given token<br>
> is visible.<br>
><br>
> For types<br>
><br>
> 1.  class, struct, or enum<br>
> 2.  derived from<br>
> 3.  derived how (public/protected/private)<br>
><br>
> For typedefs, the above must be available for all components of the<br>
> lhs.<br>
><br>
> For variables<br>
><br>
> 1.  read, write, invoke, reference, and dereference<br>
>    (A variable may be invoked if it holds a pointer to a function.)<br>
> 2.  type: class, struct, typedef, or builtin<br>
> 3.  const, static, or automatic<br>
> 4.  (overrides can be derived)<br>
> 5.  for uses, discarded Koenig lookups<br>
><br>
> For functions<br>
><br>
> 1.  for each parameter and return type, cf. "for variables", above<br>
> 2.  invoke or reference<br>
> 3.  (overrides can be derived)<br>
> 4.  for invocations, discarded Koenig lookups<br>
><br>
> For operators<br>
><br>
> 1.  declare, define, reference, or invoke<br>
> 2.  friendship (1 : many)<br>
> 3.  for invocations, discarded Koenig lookups<br>
><br>
> For the preprocessor<br>
><br>
> 1.  define or use<br>
> 2.  scope<br>
> 3.  post-processing interpretation, as above<br>
><br>
> [ceps]<br>
><br>
> As I said, I would like to know if the above information is accessible<br>
> from the clang "kit" and what, if anything, has been undertaken in this<br>
> vicinity heretofore.  If clang can provide the information, the project<br>
> I have in mind -- of writing a tool to collect it and keep it in a<br>
> database -- is both useful and feasible.<br>
><br>
> It's a big question, I know.  You can appreciate I'd want to know the<br>
> feasibility first, before diving in.<br>
><br>
> Thank you for your time.<br>
><br>
> --jkl<br>
><br>
> [1]<br>
>  <a href="http://deathrow.vistech.net/HyperReader/docs/progtool/decst124a/scasys.bkb?Chunk=48&Referer=htt&Title=ALL-IN-1%20Anv%E4ndarhandbok" target="_blank">http://deathrow.vistech.net/HyperReader/docs/progtool/decst124a/scasys.bkb?Chunk=48&Referer=htt&Title=ALL-IN-1%20Anv%E4ndarhandbok</a><br>

><br>
> P.S.  Prior to posting, I tried to read the mailing list archives.  I<br>
> must not be the first to notice they're almost impossible to read<br>
> because the text doesn't wrap in the browser.<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>