[cfe-dev] Proposal: A "Const tool" for clang

[Manuel Klimek]

On Tue, Feb 5, 2013 at 8:06 AM, Sean Silva <silvas at purdue.edu> wrote:

> > Batch
> > [...]
> > Repeat this process as long as progress ensues.
>
> Have you done a ballpark estimate of how much resident memory this
> would need for, say LLVM's codebase? Are you planning to do this
> entirely in-core? If not, then how are you planning to make this
> scale?
>
> > Interactive
> >
> > Pick as specific function parameter or method and make it const.
> > This would involve checking all of the routines that it calls with that
> parameter, and making changes to fix their interfaces (if necessary).
>
> This seems pretty ambitious. AFAIK nobody has even written a robust
> and useful tool based on Clang that coherently lets you pick a
> function and see all the call sites in a codebase (otherwise I would
> be using it!). I would recommend starting with just that aspect. My
>

That is not entirely true. There might not be an open sourced tool, but
there are publicly available ones.
This is an example from Chromium's code search:
https://code.google.com/p/chromium/codesearch#chrome/src/base/memory/ref_counted.h&q=class:scoped_refptr&sq=package:chrome&type=cs&l=254
You can click for example on the operator T*() const and get a list where
this is called throughout the Chromium codebase.

Generally, we've also internally done transformations that are very similar
in scale and complexity on our internal ~100MLOC codebase. You can make
such things scale by doing MapReduce like algorithms, which first map all
possible function calls / parameters as keys with locations, and then
basically reduce the graph of const-dependencies. Since I've implemented
MapReduce style algorithms with standard unix tools (sort, cat) this also
works for smaller problems if you don't have large infrastructure at hand.

Cheers,
/Manuel

impression is that the new Modules functionality that dgregor is
> working on will go a long way to making this easier, so pragmatically
> your time might be best spent helping to move that feature along.
>
> -- Sean Silva
> _______________________________________________
> 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/20130205/06c8e850/attachment.html>