`ImportProject` is not needed outside of the command-line parsing so we
do not need it inside the `Settings` at all. We only use the
`fileSettings` in the executors.
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 is in preparation of avoiding accessing `std::cout` directly as
well as streamlining and improving the logging during the settings
parsing. There are no functional changes yet.
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.
Both are bugprone since they just take the next parameter which doesn't
start with `-`.
Also `--template` has not been documented since
17842394c0 back in 2011(!). And
`--template-location` has never been documented since its induction in
f058d9ad08. That's also why we can have a
short deprecation period.
In cppcheck 2.11.1 (macOS), using `-j 0` actually causes cppcheck to do
nothing–it stalls indefinitely.
I could only find one place where `mSettings.jobs` was validated against
> 0 and it's simply an assert, so you wouldn't hit it in a release
build.
- Require -j >= 1 ✅
- Cap -j at 1024, not 10000 ✅ (I don't even know what would happen if
you created 10,000 threads, but nothing good; likely exhaust virtual
memory or grind the process to a halt). 1024 is still obscene but there
may be some hypercomputers out there that have that many logical cores.
Cppcheck does not report that cppcheck build dir does not exist and also
does not report any write issues to the non-existent directory.
This means that cppcheck build dir is actually not used.
We should either create the directory or fail.
* 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
Oliver Stöneberg
Ryan M. Lederman
Samuel Poláček
Daniel Marjamäki
chrchr-github