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.
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.
It was also used inconsistently and seemed to imply there is some
special handling which wasn't the case. It was just an alias for
`std::to_string()` for non-`double` types. So there was no need for it.
---------
Co-authored-by: Robert Reif <reif@earthlink.net>
This is a mess. The version is AUR is still outdated and also doesn't
install anymore. Fedora 38 carries the latest version of it so use that
now. Keep the old steps in case we need to switch again in the future.
* iwyu.yml: use debian:unstable to always get latest include-what-you-use
* cleaned up includes based on include-what-you-use
* mitigated include-what-you-use false positives
When reading earlier reported errors from the cache file the symbol names are not handled. This causes suppressions to no longer match when rerunning cppcheck.
When ErrorMessage::callStack elements are serialized to XML they are
saved in the reverse order. But when they read back from XML they are
added at the end of the list. Thus the round trip via XML reverses the
order of ErrorMessage::callStack.
From the user point of view it looks like the usage of the
--cppcheck-build-dir option sometimes (when the file wasn't reanalyzed,
but that is hard to spot) results in incorrect location info for some
diagnostic messages.
Moreover, when the first location matches some suppression rule and the
last doesn't match any (or vice versa), usage of --cppcheck-build-dir
results in some diagnostic messages appearing and disappearing seemingly
at random (again, depending on whether the file was reanalyzed or not).
Daniel Marjamäki
Oliver Stöneberg
chrchr-github
Bart vdr. Meulen
Paul Fultz II
dummyunit