Include guard naming can be validated against various patterns:
- prefixes/suffixes (`_FILE_H`, `PROJECT_FILE_H`, `FILE_H_`)
- basename/full path (`FILE_H`, `SUB_DIR_INC_FILE_H`)
- upper- or lowercase (`FILE_H`, `file_h`)
- any combination of the above (`project_sub_dir_inc_file_h_`)
A regexp can be specified to match header filenames. The example matches
any filename not starting with / and ending with `.h`, intended to match
C header files while exluding system files.
The test is not limited to naming only; validity and presence of include
guards can also be tested by setting `"required":true` in the config
file.
Enabling this feature requires adding the key `"include_guard"` to the
namingng config file used.
The namingng unit test is extended to test various features of the
include guard test.
Also, config handling is improved, adding (superficial) validation and a
unit test.
namingng.py was only usable in standalone mode, but now supports CLI
mode, i.e. with cppcheck --addon=namingng. It uses the generic reporting
provided by cppcheckdata.reportError(). All output other than reported
errors is suppressed.
A local function reportNamingError() is implemented to call through to
cppcheckdata.reportError(), filling in common defaults.
The collection of errors and the --verify feature are removed, including
related workflow and a test file. These are replaced by a unit test.
(note: comment updated after force push; initial PR was incomplete)
namingng.py attempted to derive the source filename from the name of the
dumpfile. However, the dumpfile is not necessarily named according to
this pattern, e.g. cppcheck will add the pid to the filename, making
RE_FILE rules
fail. Taking the first item of data.files seem to be more robust.
To get the basename of the file, `os.path.basename()` is used. This
solves (theoretical) issues on platforms with a different path
separator.
With this patch, all filenames are checked, not just those provided on
the cppcheck command line. This is useful as header files will now also
be part of this check, even if not explicitly specified on the command
line.
The "RE_FILE" key of the configuration JSON may contain a list of
regular expressions, where any match will lead to acceptance of the
filename.
Both the full path and the basename of the files are tested.
One use case for this combination of features is:
```
"RE_FILE":[
"/.*\\.h\\Z",
"[a-z][a-z0-9_]*[a-z0-9]\\.[ch]\\Z"
]
```
This will accept any file naming convention of the platform used
(assuming platform files are all referenced using an absolute path),
while enforcing a particular naming scheme for project files.
In case a user accidentally uses a wrong JSON file (e.g. naming.json,
which is the config file for namingng.py), the code could give a
confusing exception. This happens when the key 'script' is not defined
as a string.
This is solved by testing the key for existence and type. In case
'script' is not a key or refers to a type other than a string, a clear
error is given, stating for example: 'Loading naming.json failed. script
must be set to a string value.'
The message is kept in line with other messages. Maybe it can be
clarified further, e.g. 'Loading naming.json failed. A key "script" must
be set with a string value referring to a Python script.' - in which
case the errors relating to other keys may also be clarified.
This patch allows a config file to have RE_VARNAME and RE_FUNCTIONNAME
without the corresponding var_prefixes and function_prefixes keys. The
namingng.py processing function would otherwise raise an exception
trying to get these keys, while they are not strictly necessary, if no
prefixes are required.
As reported in
https://sourceforge.net/p/cppcheck/discussion/general/thread/fa43fb8ab1/
removeContradiction() minValue/maxValue.remove(..) can access free'd
memory as it removes all matching values by iterating over the complete
list. Creating a full copy instead of a reference avoids this issue.
Signed-off-by: Dirk Müller <dirk@dmllr.de>
The attribute movedValue is misspelled with an uppercase V, this leads
to errors when printing token values:
```
$ python3 runaddon.py test.py test.c.dump
Checking test.c.dump...
Checking test.c.dump, config ...
line 2 str=""lala\n""
Traceback (most recent call last):
File "/home/eric/tools/cppcheck/addons/runaddon.py", line 11, in <module>
cppcheck.runcheckers()
File "/home/eric/tools/cppcheck/addons/cppcheck.py", line 39, in runcheckers
c(cfg, data)
File "test.py", line 9, in func
print(f' {value}')
File "/home/eric/tools/cppcheck/addons/cppcheckdata.py", line 907, in __repr__
", ".join(("{}={}".format(a, repr(getattr(self, a))) for a in attrs))
File "/home/eric/tools/cppcheck/addons/cppcheckdata.py", line 907, in <genexpr>
", ".join(("{}={}".format(a, repr(getattr(self, a))) for a in attrs))
AttributeError: 'Value' object has no attribute 'movedValue'
```
The handling in `CppCheck::reportErr()` and `Executor::hasToLog()` was
slightly different. I hope this can somehow be shared after the executor
reworking.
We were also using a very inappropriate container for the error list
which caused a lot of overhead.
`-D__GNUC__ --debug-warnings --template=daca2 --check-library -j2
../test/testsymboldatabase.cpp`
Clang 15
main process `284,218,587` -> `175,691,241`
worker process `9,123,697,183` -> `8,951,903,360`
chrchr-github
thingsconnected
Daniel Marjamäki
Swasti Shrivastava
Paul Fultz II
Christoph Grüninger
olabetskyi
Tomo Dote
orbitcowboy
Dirk Mueller
Eric Sesterhenn
Oliver Stöneberg