[cfe-dev] #line in analyser output

[Julien Tous]

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 <file> <line> <col> 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 ?

Thanks,
Julien




2014-07-07 18:33 GMT+02:00 Jordan Rose <jordan_rose at apple.com>:

> 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?
> Jordan
>
>
> On Jul 7, 2014, at 2:42 , Julien Tous <julien.tous at gmail.com> wrote:
>
> > 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 ?
> >
> > Thanks,
> > Julien
> >
> >
> > _______________________________________________
> > 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/20140708/2f7c1e11/attachment.html>