#line in analyser output

I am using the static-analyser through scan-build command on code that has already been preprocessed by an external tool.

Although the stdout diagnostic uses the #line informations contained in the preprocessed source files, both the plist and html outputs don’t.

I would very much like to get html reports on the user written code instead of the preprocessed one.

Here come the questions :

Is there an existing way to transform a plist report into an html report ?

I could then output reports in plist, convert them using #lines information, transform them into an html report.

Are there other tools that render the plist files into a user friendly representation ?

Can someone help me to identify what is missing to directly handle the #line directive directly in the html report (i have a very limited knowledge of the toolchain right now), and comment on the difficulty of the task, and if it would make sense to integrate it ?



The plist diagnostic locations are deliberately not using #line numbers because they are intended for consumption by an IDE. If you had a (pre-preprocessed) file with #line markers in it, you wouldn't want those to screw up the plist display (and in Xcode's case, the nice arrows), especially if you no longer had the original file.

The HTML output, likewise, is built on top of being able to print the entire input file as HTML. Since Clang doesn't have any other representation of the source, it has to use the file you give it, i.e. the preprocessed file. (This is also why the HTML output cannot display cross-file issues, so it's already something we'd be willing to change.) For the text that describes the location of the bug, though, it could definitely make sense to honor #line. Clang's term for this is the "presumed location".

What is your desired output?

Actually we use some extension over the C language.

Our build process is as follow :

User C files with special macros.

→ C preprocessor →

Preprocessed C files with special macros.

→ Specialized preprocessor →

Pure preprocessed C files

→ Compiler (or analyzer)

Binary files (or report)

This build process is transparent for the developers using this “special C dialect”. All preprocessed files are temporary files.

What i would like to achieve, is to relate the reports to the user written files (not to the temporary preprocessed files).

If i understand correctly, it is not possible to do this with html output, as it is directly created from the clang AST ?

Do you consider the attribute in the plist report as the “presumed location” ? (doesn’t honor #line at the moment)

Or is the "presumed location"only the “stderr” report ? (already honor #line)

So the way to go seems to translate the plist according to the #line.

Then i need to transform them into a “manager friendly format”…

Do you know any open source tool that already perform some king of formating of clang generated plist reports that could serve as an example ?