Common error format for static analysis tools
Hi, I would like to rather see a format of lines of json documents on top of that there could be a formatted output using newstyle formatstrings (and there could even be a default format string for your proposed format) -- Ronny On 04/02/2013 10:55 PM, Vladimir Keleshev wrote:
Hi everyone, I'm very excited about the new mailing list. I wanted to share an old idea of mine, which is probably unoriginal, but can kick-start a discussion. What about all of our static analysis tools adopt a *common* machine-friendly error format, so that we could write editor plugins once, and then all of our tools would work interchangeably, and new tools could be adopted without need to update editor plugins. The proposed format could be triggered by a decided-upon option, e.g. --machine-friendly, with this usage-pattern: usage: <tool> --machine-friendly <file>... The proposed format would consist of the following lines: </absolute/path/to/file>:<start-line>:<start-char>...<end-line>:<end-char>: <error-message> For example: /home/username/git/project/project.py:65:4...65:7: Infinite `for` loop /home/username/git/project/another.py:1:1...1:5: `re` imported, but not used This is very similar to what most static analysis tools (and compilers) do anyway. But it also adds <start-char> and <end-char> which allow for precise error-highlighting in the editor. What do you think? Best, Vladimir
_______________________________________________ code-quality mailing list code-quality@python.org http://mail.python.org/mailman/listinfo/code-quality
Hello Vladimir, I would like to give some information about what is already available regarding some tools. First, you might know that there's some effort to merge the output of Pyflakes and Pep8 tools within Flake8. Today Flake8 supports all the options of Pep8 (and can be extended for plugins). For example, a useful feature is to mimic the "pylint" format with `flake8 --format pylint`. There's also a feature request which asks for JSON output for flake8. https://bitbucket.org/tarek/flake8/issue/99 This is the current state for the Flake8 tool (and its libraries). I don't know much about pylint and other tools. -- Florent 2013/4/2 Vladimir Keleshev <vladimir@keleshev.com>
Hi everyone,
I'm very excited about the new mailing list. I wanted to share an old idea of mine, which is probably unoriginal, but can kick-start a discussion.
What about all of our static analysis tools adopt a *common* machine-friendly error format, so that we could write editor plugins once, and then all of our tools would work interchangeably, and new tools could be adopted without need to update editor plugins.
The proposed format could be triggered by a decided-upon option, e.g. --machine-friendly, with this usage-pattern:
usage: <tool> --machine-friendly <file>...
The proposed format would consist of the following lines:
</absolute/path/to/file>:<start-line>:<start-char>...<end-line>:<end-char>: <error-message>
For example:
/home/username/git/project/project.py:65:4...65:7: Infinite `for` loop /home/username/git/project/another.py:1:1...1:5: `re` imported, but not used
This is very similar to what most static analysis tools (and compilers) do anyway. But it also adds <start-char> and <end-char> which allow for precise error-highlighting in the editor.
What do you think?
Best, Vladimir
_______________________________________________ code-quality mailing list code-quality@python.org http://mail.python.org/mailman/listinfo/code-quality
Regarding the output, the Flake8 tool returns <row> and <col>. And IIUC the pylint tool returns only <row>. None of these tools is able to detect and return <end-line> and <end-char>. -- Florent 2013/4/2 Florent <florent.xicluna@gmail.com>
Hello Vladimir,
I would like to give some information about what is already available regarding some tools.
First, you might know that there's some effort to merge the output of Pyflakes and Pep8 tools within Flake8. Today Flake8 supports all the options of Pep8 (and can be extended for plugins). For example, a useful feature is to mimic the "pylint" format with `flake8 --format pylint`.
There's also a feature request which asks for JSON output for flake8. https://bitbucket.org/tarek/flake8/issue/99
This is the current state for the Flake8 tool (and its libraries). I don't know much about pylint and other tools.
-- Florent
2013/4/2 Vladimir Keleshev <vladimir@keleshev.com>
Hi everyone,
I'm very excited about the new mailing list. I wanted to share an old idea of mine, which is probably unoriginal, but can kick-start a discussion.
What about all of our static analysis tools adopt a *common* machine-friendly error format, so that we could write editor plugins once, and then all of our tools would work interchangeably, and new tools could be adopted without need to update editor plugins.
The proposed format could be triggered by a decided-upon option, e.g. --machine-friendly, with this usage-pattern:
usage: <tool> --machine-friendly <file>...
The proposed format would consist of the following lines:
</absolute/path/to/file>:<start-line>:<start-char>...<end-line>:<end-char>: <error-message>
For example:
/home/username/git/project/project.py:65:4...65:7: Infinite `for` loop /home/username/git/project/another.py:1:1...1:5: `re` imported, but not used
This is very similar to what most static analysis tools (and compilers) do anyway. But it also adds <start-char> and <end-char> which allow for precise error-highlighting in the editor.
What do you think?
Best, Vladimir
_______________________________________________ code-quality mailing list code-quality@python.org http://mail.python.org/mailman/listinfo/code-quality
Hi, On 02 avril 23:46, Florent wrote:
Regarding the output, the Flake8 tool returns <row> and <col>. And IIUC the pylint tool returns only <row>.
PyLint returns column information since 0.24, released almost 2 years ago.
None of these tools is able to detect and return <end-line> and <end-char>.
None of these tool returns this information, though it would probably be possible to return sensible values in most cases (depending on the pb detected). -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org
Have you seen Firehose: https://pypi.python.org/pypi/firehose ? It currently has parsers for 3 different analysis tools (for C/C++ as it happens, though I'm sure it could support analyzers for other languages), and my cpychecker tool has a branch that "natively" uses Firehose, in that it generates errors by creating firehose.model objects in memory, then writing them out to stderr (and optionally as XML). I used this for my PyCon US 2013 talk on static analysis of Python extension modules http://lists.fedoraproject.org/pipermail/firehose-devel/2013-April/000030.ht... specifically, I used the XML serialization format to reliably extract warnings from a mass-rebuild of 370 packages, then used the JSON serialization format to get them into mongodb, which is how I generated the graphs in my talk. I also have some report-generation code using this format: http://lists.fedoraproject.org/pipermail/firehose-devel/2013-February/000005... The formats and APIs aren't yet set in stone, in case we need to make changes for analyzers for python code. Hope this is helpful Dave
participants (5)
-
David Malcolm -
Florent -
Ronny Pfannschmidt -
Sylvain Thénault -
Vladimir Keleshev