Cppcheck is the tool which analyses our CPP code. I want to create custom rule for Cppcheck to check whether all functions have comments or not. For that I need a PCRE (Pearl regex) pattern. Or any other predefined rules to address this scenarios.
There are some predefined rules available # installerlocation\cfg, what is the purpose of it? whether we can write rules using it instead of tools?
I am a cppcheck author. Yes, you can write rules using PCRE expressions. But as far as I know you can't see if there are comments from a rule. As far as I know, all comments and indentation are removed before any rules are executed.
Related
The GNU Makefile has a documentation page which lists standard implicit variables for various compilation contexts, such as CC, CFLAGS, etc. They are well defined, and pretty safe to employ (I use them all the time).
Looking though extended documentation, beyond the GNU website, I regularly see other variables which are not listed on the GNU documentation, such as COMPILER.c, LINK.o, etc.
Such variables are present in multiple recipes when looking over Github or Internet, and frequently from authors which seem to have a pretty good understanding regarding how make works.
The question is:
How reliable is it to use such variables?
They are not documented on the GNU make documentation website, but they seem stable enough that several authors have decided to rely on them. Is it a sane thing to do?
I'd say that they are documented and are pretty safe to use with GNU make (they are not in POSIX make).
However, the recipes in built-in implicit rules actually use variables such as COMPILE.c, LINK.p, and PREPROCESS.S, whose values contain the recipes listed above.
make follows the convention that the rule to compile a .x source file uses the variable COMPILE.x. Similarly, the rule to produce an executable from a .x file uses LINK.x; and the rule to preprocess a .x file uses PREPROCESS.x.
here is my Make file.
look at target olmenu-proto1, it depends on olmenu-proto1_yacc.o
But I haven't define any target called olmenu-proto1_yacc.o.
Interestingly, when I invoke make olmenu-proto1,it works!
Strangely enough!
I want to know why it would do this, thank you!
Please include the relevant bits of your makefile in your question, rather than asking people to follow a link to another site. Especially one where it's impossible to view unless you enable a lot of javascript, which many people leave mostly disabled.
In any event, most likely the reason is because make can envision how to create targets by chaining together rules, even if you don't list the prerequisites explicitly. For more information see Chains of Implicit Rules in the GNU make manual.
Is there any way to use documentary comments for test-cases defined using Boost.Test macros ? Can I use Doxygen-styled comments, will they be parsed correctly?
The answer is to make your test cases so simple, so obvious and so readable that any documentation you write is superfluous. See the section titled Test Case Maintenance and Design in my rewrite of the Boost.Test docs.
Is it possible to write your own gnatcheck rules, and if so, can someone point me to a good reference? I am searching for a particular "style" that is being used, and would love if I could simply write a rule that says if you see said style, it will throw up a warning, or an error, this way we can flag when this isn't following a particular standard.
A bit of background may be helpful here. While the style checks hold out a lot of promise for enforcing user style guidelines, that isn't exactly what they are for.
The main purpose of those checks is to enforce Ada Core's (The folks who maintain the compiler) style on the sources of the Ada compiler itself. You may notice that the checks get automatically turned on if you try compiling one of the compiler's own source files.
It doesn't really serve AdaCore's purposes at all if the styles enforced by the checks themselves are user-configurable, so they added no feature like that.
Your first option if you want to use it yourself is to just stick to AdaCore's coding style. I haven't found it horrible in the past, so you may just look at doing that.
Still, making some kind of configurability would be a really cool feature for somebody to add. If you go this route, you probably would have to make it configurable (with the current behavior as the default), rather than just changing the checks. The reason is that you'd have to modify the compiler sources to accomplish this, and as I mentioned above, the compiler turns the checks on when compiling itself. You really don't want to have to reformat a ton of working Gnat compiler source files.
I'd really like to see someone do this at some point, as it would make the checks much more useful to those of us who work for someone besides AdaCore.
In addition to trashgod's reference, I think Section 7.1 of this PDF might be of some help:
http://extranet.eu.adacore.com/articles/HighIntegrityAda.pdf
For reference, the existing GNAT style checking is described in the GNAT User's Guide under ยง3.2.5 Style Checking. As the rules are enforced by the compiler, additional rules would require corresponding modifications.
How can I know during parsing which rule is currently matched?
I'd like to automatically build an XML (or other objectal hierarchy) representing the parsed input, using rule names, without the need of using grammar actions or trees.
Is this possible?
Many thanks,
Yaakov
AFAIK, that is not possible. But why don't you use ANTLR's built in tree construction? In the options{ } part of your grammar, add output=AST; and use rewrite rules where applicable. See: http://www.antlr.org/wiki/display/~admin/2008/11/30/Example+tree+rewriting+with+patterns