[cfe-dev] null pointer literals, warnings, and fixups

[Manuel Klimek]

On Sun, Aug 21, 2011 at 9:13 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Fri, Aug 19, 2011 at 2:32 PM, Manuel Klimek <klimek at google.com> wrote:
>> On Fri, Aug 19, 2011 at 2:05 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> <snip>
>>> Side question: what tools currently exist that can actually apply
>>> fixit instructions to code? Is there any existing simple program (that
>>> would probably work like scan-build, or similar) that could be
>>> instructed to actually apply all instances of a particular warning
>>> fixup?
>>
>> We've been working on infrastructure to do exactly that, but it didn't
>> get included in mainline (see
>> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-June/015434.html,
>> which includes a patch that should still apply somewhat clean). We're
>> currently working on different options to get it open sourced.
>
> Ah, yes, I remember that thread. That's a bit of a bigger/more general
> tool than I was thinking of in this context - in this case I was just
> wondering if there was a simple tool to apply Clang's suggested
> FixIts.

That was actually the first use case we developed - a tool that you
can run that applies all fixit-hints.

> In this case if I added a warning that suggested NULL over 0
> in pointer contexts (or 0 over NULL, if that was the desired coding
> convention) & nullptr over both in C++0x, I would like to be able to
> say "apply all fixups from this warning" & then I could easily
> transform a codebase over to nullptr (or maintain 0/NULL usage in
> C++98).
>
>> The architectural idea is that you have a clang-fixit tool that uses
>> cmake's ability to output compile commands to apply all possible fixes
>> that clang suggests on a file.
>
> So you'd take all of cmake's output then filter it through some tool
> to grab the compile commands, replace the compiler name with your tool
> & then your program uses clang as a lib to produce fixits & act on
> them? Neat.

Close. I implemented a feature in CMake itself to write out all
compile commands into a .json file during generation time. This is
also useful for IDEs (eclipse for example is planning to use that
information for its project generation).
The patch I referred to implements a simple tooling class to which you
hand a frontend action, and the tooling infrastructure reads the .json
file, finds the compile command line for all files you want to run on,
and then runs clang with your specified frontend action over those
files.

> Though I wonder if it'd be possible/better/worse to use
> the clang static analyzer's scan-build approach of injecting itself
> into the compilation process & splitting - running both the analyzer
> (fixer) & compiler at the same time. Relying on cmake would only work
> for people using that build system, scan-build seems to be a little
> more versatile.

Both are valid use cases. Requiring a build is often too expensive
when you want to get really fast feedback to a developer for
incremental small changes (delivering functionality that's close to
what IDEs do for people who use them).
Also, if you want to run the tool many times over the same code, you
can perfectly shard and thus parallelize the tool, whereas the build
would still follow the dependency bottlenecks.
Third, the tool supports virtual file systems, which helps if you want
to run over code that you don't have on a file system.
Forth, you often want more control over the flow when doing tooling -
for example, when implementing a refactoring, you need a source
manager that is only used to apply all the refactorings and is
independent of the TUs that were run, and you need to do this after
all runs finished; also, your tool might want to use a special
diagnostic printer etc.

On the other hand being able to run as a plugin during compile time is
important when you want to annotate the build output with more
information (for example break the build on certain errors, run
analysis during your buildbot compiles, etc). Which is why I think
both are good use cases with different limitations.

Cheers,
/Manuel