`namingng.py` somewhat supported specifying a dict instead of a list for
regular expressions, until the feature was broken by a patch of mine
recently. This PR contains a patch rewriting the feature and expanding
relevant unit tests.
To improve maintainability, a second patch is added that refactors the
code for better readability and structure.
For naming issues reported, column was always set to `0`, which is now
fixed.
Global variable naming errors were reported as "Public member" issues,
which is also fixed.
The unit test now covers namespaces, class names, public and private
member variables.
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.
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.
Currently the `AddonInfo` is generated and discarded on each addon
invocation. This leads to an unnecessary process invocation for each
addon on each file.
Also if an addon is completely broken we will still perform the whole
analysis only for it to be failed at the end so we should bail out early
if we know it doesn't work at all.
This is a step onto leveraging the `ThreadExecutor` implementation for
`ProcessExecutor` which is a follow-up to #4870. We need to have the
proper test coverage and the existing implementations working as
expected before we move to the shared code.
Fixes:
- added `--showtime=` tests for all executor implementations
- only print `--showtime=summary` once at the end
- prevents `--showtime=` by multiple threads to be written at the same
time - essentially breaking the output
- reset the timer results before each test
- deprecated `top5` in favor of `top5_file`
- fixed printing for all executors except `ProcessExecutor`
This makes the code much more readable. It also makes it less prone to
errors because we do not need to specify the length of the string to
match and the returnvalue is clear.
The code with the bad returnvalue check was never executed and I added a
test to show that.
Encountered while investigating https://trac.cppcheck.net/ticket/11708.
This has been like this since the introduction of `internalError` in
b6bcdf2936 (almost ten years ago to the
day). Logging internal errors which bail out(!) of the analysis simply
to `std::cout` for them possibly never to be seen (and also not affected
the exitcode) is pretty bad IMO. They should always be visible.
I also removed the filename from the message as it is already available
(and thus redundant) and its existence should be defined by the
template.
This was introduced in #5279. We were transferring the terminating `\0`
via the pipe and also added another one in the parsing. As we are now
directly writing into a `std::string` these extra characters will now
show up in it. So just get rid of them.
* Preprocessor: cleaned up `missingInclude()`
* Preprocessor: relaxed dependency on `Suppressions` / adjusted `TestPreProcessor::inline_suppression_for_missing_include()` which was not testing production behavior
* test/cli/test-other.py: added test for `missingInclude` and `missingIncludeSystem` inline suppressions
* fixed `constParameterReference` selfcheck warning
* dump: Fix concurrency problem with dump files
This adds the process ID for the cppcheck process to the filenames
of the .dump and .ctu-info files that the process generates.
So
lib/cppcheck.cpp.dump
becomes
lib/cppcheck.cpp.<PID>.dump
For example:
lib/cppcheck.cpp.2637871.dump
The reason for this change is that if there is a buildsystem which
supports concurrency, multiple instances of cppcheck may be run for
the same file. For example, if the same file is compiled in multiple
build variants, or for multiple targets.
If running the MISRA plugin over such a project with concurrency
enabled in the buildsystem, the plugin ends up crashing as multiple
jobs attempt to create/trample/delete the same files while other
jobs are using them.
For more information see:
https://sourceforge.net/p/cppcheck/discussion/general/thread/02c757b4af/
* dump: Include pid in filename if dump not explicit
Only change the dump and ctu-info filenames to include the PID if
they are being generated due to an addon.
This means that existing scripts that use `--dump` will still work
if they depend on the previous naming behaviour. The more robust
filenames containing the pid will be used when the dump files are
used as an internal implementation detail for passing data to addons.
However this means that anything that does explicitly use `--dump`
will be susceptible to concurrency problems.
* test: Update addon dump file test to account for pid
This test causes a dump file to be created by enabling the misra
addon. Since the dump files now include the cppcheck process pid
this test had to be updated to account for the change.
Oliver Stöneberg
Maarten van der Schrieck
thingsconnected
Daniel Marjamäki
chrchr-github
Michael Drake