I'm pleased to announce the availability of Vera++: http://www.inspirel.com/vera/ Vera++ is a programmable tool for verification, analysis and transformation of C++ source code. It relies on embedded scripting language for rule definition to provide maximum flexibility and extensibility. This tool might be of interest to the Boost community for two reasons: First, it uses boost::wave for parsing code. I would like to thank Hartmut Kaiser for this masterpiece. The second reason is this: http://www.inspirel.com/vera/ce/demo.html ;-) -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Hi, I tried to compile Vera++ - but get following error: Entering directory `/tmp/vera++-1.0.0/src/structures/lexer' make[2]: *** no rule for target /libs/wave/src/cpplexer/re2clex/aq.cpp, required by aq.o. Any hints? Regards, Oliver
I'm pleased to announce the availability of Vera++:
Vera++ is a programmable tool for verification, analysis and transformation of C++ source code.
It relies on embedded scripting language for rule definition to provide maximum flexibility and extensibility.
This tool might be of interest to the Boost community for two reasons:
First, it uses boost::wave for parsing code. I would like to thank Hartmut Kaiser for this masterpiece.
The second reason is this:
http://www.inspirel.com/vera/ce/demo.html
;-)
-- Maciej Sobczak * www.msobczak.com * www.inspirel.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Oct 01, 2007 at 11:14:10AM +0200, Oliver.Kowalke@qimonda.com wrote:
Hi, I tried to compile Vera++ - but get following error: Entering directory `/tmp/vera++-1.0.0/src/structures/lexer' make[2]: *** no rule for target /libs/wave/src/cpplexer/re2clex/aq.cpp, required by aq.o.
Any hints? The build system expects BOOST_DIR (or whatever it's called) to point to the boost sources, not a location of an installed boost.
Jens
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Maciej Sobczak Sent: 01 October 2007 08:37 To: boost@lists.boost.org Subject: [boost] Vera++
I'm pleased to announce the availability of Vera++:
Vera++ is a programmable tool for verification, analysis and transformation of C++ source code.
It relies on embedded scripting language for rule definition to provide maximum flexibility and extensibility.
This tool might be of interest to the Boost community for two reasons:
First, it uses boost::wave for parsing code. I would like to thank Hartmut Kaiser for this masterpiece.
The second reason is this:
This looks an *excellent* aid to code consistency. When will we see version 2 - that actually edits source to conform ;-)) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
This looks an *excellent* aid to code consistency.
Yes, this is one of the targets.
When will we see version 2 - that actually edits source to conform ;-))
No need for version 2, actually - Vera++ can also transform code. Most of the rules have simple corrections than can be automated. For example, there is a rule that forbids trailing whitespace. Interestingly, there is also a transformation that removes them. Simple. The problem is that not all rules can have such straightforward corrective actions. For example, the rule that forbids identifiers composed of only 'l' and 'O' characters has no reasonable corrective action other than the human developer just coming up with better names. In any case, your suggestions in all these areas are highly welcome. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
I think it is appalling that such a whining creature - nagging and nagging for 300k lines - should carry a woman's name. /David On Oct 1, 2007, at 8:49 AM, Maciej Sobczak wrote:
Paul A Bristow wrote:
This looks an *excellent* aid to code consistency.
Yes, this is one of the targets.
When will we see version 2 - that actually edits source to conform ;-))
No need for version 2, actually - Vera++ can also transform code. Most of the rules have simple corrections than can be automated. For example, there is a rule that forbids trailing whitespace. Interestingly, there is also a transformation that removes them. Simple.
The problem is that not all rules can have such straightforward corrective actions. For example, the rule that forbids identifiers composed of only 'l' and 'O' characters has no reasonable corrective action other than the human developer just coming up with better names.
In any case, your suggestions in all these areas are highly welcome.
-- Maciej Sobczak * www.msobczak.com * www.inspirel.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
Paul A Bristow wrote:
This looks an *excellent* aid to code consistency.
No need for version 2, actually - Vera++ can also transform code. Most of the rules have simple corrections than can be automated. For example, there is a rule that forbids trailing whitespace. Interestingly, there is also a transformation that removes them. Simple.
It's indeed very interesting. My coworkers have started using some code consistency/checking tools which do similar things. Vera++ seems extremely interesting but the lack of built-in rules prevents adoption. Furthermore these scripts aren't easily configurable, they have to be hand-edited at invocation. This implies having a bunch of shell scripts to do anything robust. Having a configuration file which allows the selection of rules & filters as well as their parameterization would be interesting. Having a GUI for this configuration file would be even better. Don't get me wrong: I really like what you did, I just don't think it's quite "there" yet. JF
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Maciej Sobczak Sent: 01 October 2007 08:37 To: boost@lists.boost.org Subject: [boost] Vera++
I'm pleased to announce the availability of Vera++:
Vera++ is a programmable tool for verification, analysis and transformation of C++ source code.
It relies on embedded scripting language for rule definition to provide maximum flexibility and extensibility.
You might like to add to the default rules a check that all files end in a newline (as required by the C++ Standard). This will prevent files that do not comply causing an abrupt end to compilation if one tries to be uber-virtuous and Uses MSVC warning level 4. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
You might like to add to the default rules a check that all files end in a newline (as required by the C++ Standard).
It is there already, as a built-in rule. This rule is built-in, because checking it systematically made it easier to accommodate the rest of the engine. This should be just added to the documentation. :-) Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Maciej Sobczak wrote:
You might like to add to the default rules a check that all files end in a newline (as required by the C++ Standard).
It is there already, as a built-in rule.
BTW (from 1.34.1): ./libs/iostreams/test/code_converter_test.cpp:337: no newline at end of file ./libs/math/tools/generate_test_values.cpp:32: no newline at end of file ./libs/pool/test/sys_allocator.hpp:100: no newline at end of file ./libs/serialization/test/polymorphic_text_warchive.hpp:18: no newline at end of file ./libs/spirit/example/intermediate/simple_xml/driver.cpp:45: no newline at end of file ./libs/spirit/example/intermediate/simple_xml/tag.cpp:46: no newline at end of file ./libs/spirit/example/intermediate/simple_xml/xml_g.hpp:186: no newline at end of file ./libs/spirit/fusion/test/insert_tests_mpl.cpp:49: no newline at end of file ./libs/wave/test/testwave/testfiles/t_6_063.hpp:45: no newline at end of file ./libs/wave/test/testwave/testfiles/t_6_066.hpp:46: no newline at end of file ./tools/inspect/wrong_line_ends_test.cpp:5: no newline at end of file Unfortunately, there is (currently) no way to run this built-in rule alone, so the above is part of some bigger report. I guess only the last three above were intentional. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Maciej Sobczak Sent: 04 October 2007 15:23 To: boost@lists.boost.org Subject: Re: [boost] Vera++
Maciej Sobczak wrote:
You might like to add to the default rules a check that all files end in a newline (as required by the C++ Standard).
It is there already, as a built-in rule.
BTW (from 1.34.1):
./libs/iostreams/test/code_converter_test.cpp:337: no newline at end of file ./libs/math/tools/generate_test_values.cpp:32: no newline at end of file ./libs/pool/test/sys_allocator.hpp:100: no newline at end of file ./libs/serialization/test/polymorphic_text_warchive.hpp:18: no newline at end of file ./libs/spirit/example/intermediate/simple_xml/driver.cpp:45: no newline at end of file ./libs/spirit/example/intermediate/simple_xml/tag.cpp:46: no newline at end of file ./libs/spirit/example/intermediate/simple_xml/xml_g.hpp:186: no newline at end of file ./libs/spirit/fusion/test/insert_tests_mpl.cpp:49: no newline at end of file ./libs/wave/test/testwave/testfiles/t_6_063.hpp:45: no newline at end of file ./libs/wave/test/testwave/testfiles/t_6_066.hpp:46: no newline at end of file ./tools/inspect/wrong_line_ends_test.cpp:5: no newline at end of file
Unfortunately, there is (currently) no way to run this built-in rule alone, so the above is part of some bigger report.
Hmmm - I could see it getting lost in the barrage of nags!
I guess only the last three above were intentional.
Useful - though I also wonder if this trivial but annoying detail could/should be checked by SVN? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
Useful - though I also wonder if this trivial but annoying detail could/should be checked by SVN?
If you start checking things, you will never stop adding rules. :-) That's how Vera++ was actually born. If you ask whether Vera++ could be plugged in SVN (possibly with your modified profile and your favorite parameters), then yes, I think so. It's just a command-line tool. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Maciej Sobczak wrote:
If you start checking things, you will never stop adding rules. :-)
After extending one of them (coming soon) I've found this: ./libs/graph/src/graphviz_digraph_parser.cpp:253: reserved name used for macro (keyword or alternative token redefined) ./libs/graph/src/graphviz_graph_parser.cpp:253: reserved name used for macro (keyword or alternative token redefined) In both cases it is the following: #define const This must be a new form of const-correctness, right? :-) Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Maciej,
If you start checking things, you will never stop adding rules. :-)
After extending one of them (coming soon) I've found this:
./libs/graph/src/graphviz_digraph_parser.cpp:253: reserved name used for macro (keyword or alternative token redefined) ./libs/graph/src/graphviz_graph_parser.cpp:253: reserved name used for macro (keyword or alternative token redefined)
In both cases it is the following:
#define const
This must be a new form of const-correctness, right? :-)
Would it be possible to implement all the rules currently enforced by the Boost inspect tool? We could then retire this and use Vera++ instead, which allowed us to be more flexible wrt the rule to enforce. BTW: Inspect allows to switch off certain tests for a particular file by inserting special comments into this file. Does Vera++ support something like this? Regards Hartmut
Hartmut Kaiser wrote:
Would it be possible to implement all the rules currently enforced by the Boost inspect tool?
I would need to see what inspect does before answering this question.
BTW: Inspect allows to switch off certain tests for a particular file by inserting special comments into this file. Does Vera++ support something like this?
Currently, this is not built-in. However, the rules themselves might contain appropriate check - after all, they see all tokens, including "special" comments. But I would rather do it differently and externally to the source files in question - make a separate list of "exceptions" and feed it to Vera++. This way the files themselves would be free of any such "meta"-mess and they would not need to change just because some day somebody decides to use another checking tool. Does it make sense? In any case, this functionality seems to be needed, so will be added to the next release of the tool. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Maciej Sobczak wrote:
I'm pleased to announce the availability of Vera++:
Vera++ is a programmable tool for verification, analysis and transformation of C++ source code.
It relies on embedded scripting language for rule definition to provide maximum flexibility and extensibility.
This tool might be of interest to the Boost community for two reasons:
First, it uses boost::wave for parsing code. I would like to thank Hartmut Kaiser for this masterpiece.
The second reason is this:
http://www.inspirel.com/vera/ce/demo.html
;-)
What would also be nice is ability to define macros and values for them. Sometimes there are macros which break the syntax and you need to replace them before actually parsing the C++ code. And there is a lot of code with this. Doxygen has the feature I describe. Take a look here: http://www.stack.nl/~dimitri/doxygen/preprocessing.html - I mean PREDEFINED thing.
On 10/1/07, Maciej Sobczak <prog@msobczak.com> wrote:
I'm pleased to announce the availability of Vera++:
Vera++ is a programmable tool for verification, analysis and transformation of C++ source code.
It relies on embedded scripting language for rule definition to provide maximum flexibility and extensibility.
This tool might be of interest to the Boost community for two reasons:
First, it uses boost::wave for parsing code. I would like to thank Hartmut Kaiser for this masterpiece.
The second reason is this:
This looks like a very useful tool, thanks for releasing this! Here are some binaries for anyone on Windows: http://phrosty.phoenixlabs.org/vera++.bin.7z And the VC++ project I used: http://phrosty.phoenixlabs.org/vera++.src.7z -- Cory Nelson
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Cory Nelson Sent: Sunday, October 07, 2007 10:22 AM To: boost@lists.boost.org Subject: Re: [boost] Vera++
I'm pleased to announce the availability of Vera++:
Vera++ is a programmable tool for verification, analysis and transformation of C++ source code.
It relies on embedded scripting language for rule definition to
On 10/1/07, Maciej Sobczak <prog@msobczak.com> wrote: provide
maximum flexibility and extensibility.
This tool might be of interest to the Boost community for two reasons:
First, it uses boost::wave for parsing code. I would like to thank Hartmut Kaiser for this masterpiece.
The second reason is this:
This looks like a very useful tool, thanks for releasing this!
Here are some binaries for anyone on Windows: http://phrosty.phoenixlabs.org/vera++.bin.7z
And the VC++ project I used: http://phrosty.phoenixlabs.org/vera++.src.7z
-- Cory Nelson _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Wow I had no idea so many tabs crept into my code. When you report that a rule was broken I think you should list the rule name (i.e, L002) and any transforms that could be used to fix the rule afterwards. This way I can quickly run with the right transform and/or look up help on the rule. I look forward to hearing about more rules and transforms. If people start crafting more rules then this would be useful to me. Also I noticed that in this binary you can turn rules off or on selectively, which is nice. I was worried about that when I saw the other posts in this thread. -- John
John Femiani wrote:
I'm pleased to announce the availability of Vera++:
Wow I had no idea so many tabs crept into my code.
:-)
When you report that a rule was broken I think you should list the rule name (i.e, L002)
Yes, this will be useful.
and any transforms that could be used to fix the rule afterwards.
It's not that simple. The rules are just scripts and the set of scripts can be different on each installation. Same for transforms. In general, rules have no idea about transforms and their meaning, so they cannot recommend anything. On the other hand, some recommendations can be included in the documentation of each rule - at least those which are provided together with the tool. To be frank, I'm not a big fan of automatic correction of code. This concept assumes that the *intended* form can be automatically deduced. At the same time I assume that any violation is actually a question mark about the original intentions and that it can be reliably resolved only by human (I don't trust the code which was "fixed" without me being involved). These two assumptions are (philosophically) incompatible.
I look forward to hearing about more rules and transforms.
Some are already in the pipeline, coming soon.
Also I noticed that in this binary you can turn rules off or on selectively, which is nice.
Of course. You can define your own profile files and parameter files and you can have many of them (imagine working on different projects that have different conventions).
I was worried about that when I saw the other posts in this thread.
Somebody didn't check it before posting. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Maciej Sobczak Sent: Wednesday, October 10, 2007 12:31 AM To: boost@lists.boost.org Subject: Re: [boost] Vera++ <snip>
and any transforms that could be used to fix the rule afterwards.
It's not that simple. The rules are just scripts and the set of scripts can be different on each installation. Same for transforms. In general, rules have no idea about transforms and their meaning, so they cannot recommend anything. On the other hand, some recommendations can be included in the documentation of each rule - at least those which are provided together with the tool.
To be frank, I'm not a big fan of automatic correction of code. This concept assumes that the *intended* form can be automatically deduced. At the same time I assume that any violation is actually a question mark about the original intentions and that it can be reliably resolved only by human (I don't trust the code which was "fixed" without me being involved).
These two assumptions are (philosophically) incompatible. <snip> -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
I was not trying to suggest automatically correcting the problems; I was only suggesting that when the rules are crafted it would be useful if the names of any relevant transforms were listed after the message so I would know what to do. For example you could have a --verbose option that gives hints, so instead of just aligned_storage.hpp:160: trailing whitespace you could say: aligned_storage.hpp:160: [L001] trailing whitespace -fix1: vera++ -transform trim_right aligned_storage.hpp -fix2: vera++ -transform som_other_transform aligned_storage.hpp Actually the reason I suggested that was because I got the message about tabs and could not find a transform to fix it, even though I expected there to be one. I assume that you just haven't gotten around to that one yet :) Also I have used eclipse in the past for Java programming and that IDE does an incredible job at suggesting corrections and applying them. The IDE puts an icon next to a line if there is a syntax error or if there is a code analysis rule (like a vera++ rule) that is broken at the line. When you right click on the icon you can choose from a list of possible actions to fix the problem. I do not know of a c++ editor or IDE with this feature but I think that if Vera++ can provide a consistent syntax for listing suggestions then authors of editors could write plug-ins for it (or maybe I am just dreaming). Actually the Java tool lets you put special comments in to instruct the analyzer to ignore messages on the next statement. For your program it could be something like: //@ignore_rule L001 That makes sure the analyzer doesn't flag it as a warning and it lets any other reader know that you deliberately chose to break convention for some reason. I'm just putting that out there. :-) -- John
Hello John, Maciej, On 10/10/2007, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
For example you could have a --verbose option that gives hints, so instead of just
aligned_storage.hpp:160: trailing whitespace
you could say:
aligned_storage.hpp:160: [L001] trailing whitespace -fix1: vera++ -transform trim_right aligned_storage.hpp -fix2: vera++ -transform som_other_transform aligned_storage.hpp
What about only mentioning that at the bottom or in the manual? If you list all possible fixes for each bug, you get the output that c++ gives on not defining an operator<< for a user class - pages of other options that you really never intended to use. Regards, Peter
Hi, I would consider On 10/10/07, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
aligned_storage.hpp:160: [L001] trailing whitespace -fix1: vera++ -transform trim_right aligned_storage.hpp -fix2: vera++ -transform som_other_transform aligned_storage.hpp
I would consider that more like a plugin for whichever IDE you are using --or a command line report processor. An example would be using a plugin for Eclipse CDT --now that you mention it--, that runs vera, processes the output and adds suggestions that are integrated in the IDE project. For us using plain editors and command line tools, someone (not necessarily Vera++ makers) could come up with a wrapper that suggests solutions. Internalizing those suggestions into the tool seems unneeded and cumbersome.
//@ignore_rule L001
I agree on this with some previous post: I don't think that is a good option, mainly for two reasons. First it implies adding comments in the code to control some external tool, second if you start that path, you'll end up with a comment to control how vi indents, emacs options, vera++ options, another tools options... David
David Rodríguez Ibeas wrote:
On 10/10/07, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
aligned_storage.hpp:160: [L001] trailing whitespace -fix1: vera++ -transform trim_right aligned_storage.hpp -fix2: vera++ -transform som_other_transform aligned_storage.hpp
I would consider that more like a plugin for whichever IDE you are using
Yes. The next release of Vera++ will be able to include the rule number in the report line if some command-line option is given. This will be very easy to parse/extract and then linked with any behaviour needed. Note also that it is typical for a single rule to trigger *many* times on a larger body of code. It would not be very comfortable to get these hints repeated thousand times.
//@ignore_rule L001
I agree on this with some previous post: I don't think that is a good option
Similarly, Vera++ will support lists of exclusions, which will be provided *externally*. There is no need to be intrusive in the code itself to achieve this. Note also that proper implementation of exclusion lists will allow to handle whole groups of files - for example all files from specific directory (this actually makes sense in Boost, especially for files that are test cases for wave - they intentionally break all possible rules). It would be inefficient to impose comments like above into such files, especially if it could interfere with the parser test case that a given file is supposed to implement. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
//@ignore_rule L001
I agree on this with some previous post: I don't think that is a good option, mainly for two reasons. First it implies adding comments in the code to control some external tool, second if you start that path, you'll end up with a comment to control how vi indents, emacs options, vera++ options, another tools options...
David
Line numbers change a lot when files are edited so how would an external file deal with line-by-line exclusion? Also if one of the points of an analysis rule is to help enforce a convention, isn't _also_ nice to show in the source that you deliberately chose to break convention? If this is one of those never ending controversies that is cool. I just personally like in-lining stuff (like using doxygen). BTW a Vera++ rule exclusion does not seem like vi or emacs preferences as I understand it. Somehow analysis rules, especially where they are broken, seem like they are an important part of the code itself. If a rule should be excluded from a part of a file, that is not just a matter of one users preference. Maybe the better analogy would be pragmas that enable or disable compiler warnings in a source file (VC8), or the inline structured comments allowed by doxygen. Also I was trying to follow the convention I have seen in eclipse, which uses inline comments for Java. (I don't know what the underlying analysis tool being used was) -- John
participants (12)
-
Alexei Alexandrov -
Cory Nelson -
David Bergman -
David Rodríguez Ibeas -
Hartmut Kaiser -
Jean-Francois Bastien -
Jens Finkhäuser -
John Femiani -
Maciej Sobczak -
Oliver.Kowalke＠qimonda.com -
Paul A Bristow -
Peter Bindels