This is a warning we found during static analyis with CodeSecure
CodeSonar.
It flagged a suspicious copy-paste error, where it finds code that seems
to have been copied from another location, with some, but not all,
variables substituted.
Unclear to me if this truly is a problem, or intentional, but I wanted
to provide the feedback as I am not sure how to test this.
Lines 5614 to 5619 in lib/symboldatabase.cpp are a copy from 5597-5602
with vartok replaced by valuetok, except for line 5616
We were calling several interface functions through their inherited
classes instead of using the base classes requiring us to add `friend`
declarations to make the implementations accessible. This adjusts
several of those cases.
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.
Windows XP Pro x64 was released on April 25, 2005 and consumer
processors supporting x86-64 have been around almost as long. Although
there are still 32-bit Windows images available there is not much of a
point maintaining support for these. We also never did any x86 builds
for non-Windows platforms in CI so we don't even know if we work on
those. You might still be able to build 32-bit binaries via CMake.
This used to be one of the longest running jobs because of the slow
setup and linking. Now it will take only ~2 minutes if everything is
cached with half the time taken up by the tests.
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.
Scanning the `cli` folder with `DISABLE_VALUEFLOW=1` `Tokenizer::dump()`
will consume almost 25% of the total Ir count when an addon is
specified. This is mainly caused by the usage of `std::ostream`.
Encountered while profiling #4958.
Still ran into an assert failure in `Tokenizer::hasIfdef()`, since some
checks assume that the tokenizer is always present. Seems like
clangimport is yet another rogue under-tested feature...
Mark Hermeling
Paul Fultz II
chrchr-github
Daniel Marjamäki
Oliver Stöneberg