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...
This adds a new checker to check for pointer to bool conversions that
are always known. I removed the previous knownConditionTrueFalse checks
since this was too noisy.
There was no need for the `Tokenizer` parameter to be a pointer as it
could never be `nullptr` and was also dereferenced without checking
first.
As a reference to the `Settings` was already available via the
`Tokenizer` there was no need to pass it separately. In the production
code there will only be one instance of it but in the tests we could
have accidentally passed a different one.
Oliver Stöneberg
chrchr-github
Daniel Marjamäki
Paul Fultz II