test_showtime_top5_file() assumes that all reported elements, of which
the "top 5" are validated, end with the string "- 1 result(s))".
This is clearly not the case when viewing the entire list:
```bash
$ cppcheck --showtime=summary --quiet empty.c |grep "2 result"
valueFlowLifetime(tokenlist, errorLogger, settings): 3.4e-05s (avg. 1.7e-05s - 2 result(s))
valueFlowEnumValue(symboldatabase, settings): 3e-06s (avg. 1.5e-06s - 2 result(s))
```
As the order of items is non-deterministic, this test makes CI workflows
randomly fail.
This patch addresses the issue by adjusting the expected string to the
reported item.
In particular, the missing definition of `g_assert_nonnull()` can cause
false positives because it's not recognized as `assert(expr != NULL)` by
cppcheck.
The current versions only have partial C++11 support which fortunately
has caused us only few issues so far but it would be good to finally
have fully working C++11 support. This also gets rid of several CI
builds on very outdated platforms.
The outdated platforms were used to also test CMake 2.8 but as future
versions of CMake will drop combability with CMake < 3.5 this is a good
time to also drop that requirement on our part.
This PR does not remove or update any outdated code.
`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.
Although these files are part of our repo changes are being done via
their original projects so it might make sense to treat these as system
includes for some people instead of local ones.
Co-authored-by: Daniel Marjamäki <daniel.marjamaki@gmail.com>
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.
Daniel Marjamäki
Oliver Stöneberg
Maarten van der Schrieck
orbitcowboy
chrchr-github
Philip Chimento
thingsconnected
Swasti Shrivastava
Paul Fultz II
Christoph Grüninger