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.
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
* cleaned up triage.pro and pass all triage files to selfcheck
* CI-unixish.yml: factored out redundant selfcheck flags
* CI-unixish.yml: cleaned up selfcheck suppressions and fixed warnings
* added explicit `missingInclude` checks to selfcheck to work around current issues/limitations / fixed selfcheck includes / added some unit tests for `missingInclude`
* applied the selfcheck changes to the sanitizer jobs
* only fail TSAN CI build in case of TSAN error / updated sanitizer CI build TODOs
* Fix false negatives in checkBitwiseOnBoolean
Use AST-based tests in favor of token-based tests for greater coverage.
* Travis: add suppressions for bitwiseOnBool
* Fix false negatives in checkAssignBoolToFloat
Detect assignments to expressions involving pointer dereferences, array
element accesses, etc.
* Pass assignment token to assignBoolToFloatError
Pass assignment token rather than boolean token to make error reporting
consistent between checkAssignBoolToFloat and checkAssignBoolToPointer,
as well as with other assignment checks in the code base.
* Make checkAssignBoolToPointer check consistent with checkAssignBoolToFloat
A common pattern is to have a function like similar to this:
bool isFlagSet(uint32_t f) {
return f & 0x4;
}
Warning that the function returns a non-boolean in this case is too
noisy, it would be better suited for a Misra check, so remove the
warnings in the most obvious cases.
* Add check for return value of boolean function
The rule for converting an integer to a boolean is that 0 is mapped to
false and everything else is mapped to true. There is nothing wrong with
the following code (according to the standards):
bool f()
{
return -1;
}
and neither gcc nor clang will warn about it. However, it's a bit
confusing. This commit adds a check that warns when a value other than 0
or 1 is returned from a boolean function (similar to the existing check
that functions with boolean arguments are only passed 0 or 1). Since the
code is perfectly legal, set the severity to "Style".
* Use early continue and remove some braces
* Add testcase with multiple returns
* Avoid null pointer dereference in case of return without operand
* Skip lambdas
Add TODO-test cases that shows FPs when the return type of lambdas are
specified explicitly (this is a problem with findLambdaEndToken).
* Enable testcases