analysis vs fixit

Hi,

I have written a tiny coding convention checker, see attachment. You're
very welcome to include it (after a long period of tough reviews :-).
It's really only a proof-of-concept for now, missing basic things like
validation ("do we have a config file?"), customization, and: fixit. And
because I'm still a novice to clang I'm sure that it's a) suboptimal and
b) wrong :slight_smile: I will definitely benefit from your comments.

The fixit problem is that the convention checker (also according to
Mike, see
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-October/006633.html&gt;\)
should be seen as an analysis. But if the frontend does analysis I don't
see how it can do fixit :frowning: Any suggestions? Shouldn't -fixit and
-analyze be both allowed at the same time? Or am I misunderstanding some
basic concept here?

Cheers, Axel.

CodingConvention.tar.bz2 (7.89 KB)

coderules.txt (587 Bytes)

Hi Axel,

The -analyze option activates the static analyzer component, which uses an entirely different mechanism for reporting bugs than the frontend. It should be viewed as a separate tool. The analyzer happens to use Diagnostics to output information about static analyzer reports to the console, but that's only as an aid. Fixit support needs to be properly added to the BugReport and BugReporter classes in order for the static analyzer to support fixits (as well as supporting a workflow for fixits in the static analyzer "GUI", e.g. scan-view).

I'd interpret '-fixit' as a frontend option that has nothing to do with the static analyzer. Once fixits are supported by the static analyzer, they'll be incorporated into the GUI for viewing analyzer reports.

Ted

Hi @Ted_Kremenek, what do you mean by “properly added” to the Bug* classes? It seems like this answers my question here:

It’s been a long time but has this been changed since the original post?