Added a new option "-p" to test.pl to request printing failure logs instead of
doing so via an external script. This simplifies various Makefiles and enables
use in cmake builds.
Only give warnings for namespaces with actual names, in accordance with
ad41375353.
This enables the use of anonymous namespaces without warnings.
Fixes: #932
Now directly test individual lines with perls regex matching rather than
calling out to grep. Some changes were required:
- escape (, ) if we want to match them
- unescape (, ) if we want to use them as regex bracket groups
- escape +, $ if we want to use them as actual characters
- unescape + to use as a regex +
Throw statements should not have the bracket and the first character of
the error message should be lower case. Added a check to the linter to
verify this. Added regression tests to check this.
Modified the inital regex to require a word character immediately
(except spaces) before the bracket. This ensures we are not just a order
of operations bracket but in fact a function call. Added a regression
test that checks the case that this is required for
Previously the regex was checking for the first parameter being on the
first line, but this isn't required for the function call to be wrong.
Added the check for each of the lines if there is no nested function
call.
Instead use a more complex system that finds the matching closing
bracket and checks all the lines in between to check one parameter only
on each line.
It handles nested function calls by skipping over their whole parameter
list (since we don't require nested functions be separated onto
individual lines just because the outer call is. Instead these get
checked when we get to this function call separately.
The regex for finding operator functions didn't work if the function
belonged to a class as it wasn't matching the :: correctly. Extended the
regression test to cover this
We attempt to validate that the */& for pointer/reference types are
attached to the variable rather than the type. For example should be int
*x; rather than int* x;
We attempt to check this by looking for things that are at the very
start of the line and not in brackets to avoid picking up cases where
the * or & is used as a binary operator.
We can still miss cases inside a function declaration.
Updated the coding standard to also explicityl mention this preference
Previously we were only allowing << around digits, but this produces
false positives as there are plenty of uses of the shift operator that
use variables. At this stage, I believe it is better to just remove this
check.
The old way of checking for classes ended in t was confusing as used a
negative match. As such it was difficult to check that it ended in a t
but count & or * as the terminator of the type. We start the search at
a bounardy to deal with classes inside brackets but not when class is
part of a larger word.
Instead we now just try and match the name since this will greedly
consume the whole name and nothing more.
The template check also uses boundary rather than the start line anchor
since sometimes template statements can be indendented. However in
these cases we still don't want to check the type ends in a t.
This stops us incorrectly reporting types not ending in t as we don't
erronousely treat other chartacers as the final charatcer of the type.
Added some extra tests to deal with the variety of ways that the class
keyword can appear in the codebase.
Previously we would always checkf for function header comments if we
found a function. Now if we find a ; before a { then we assume it is a
function declaration, otherwise we assume it is a function
implementation and therefore should have the function header comment.
This does mean that functions with bodies in header files are going to
require a function header comment.
Since operator functions can have non-word characters as part of their
name (specifically, can have an opening bracket) we deal with these
seperately in the explicit case where the functions name is operator.
Since the function name can now contain non-word characters (e.g. an
opening bracket) we must escape it before using it in the regex.
When checking for function comments we don't want to include the * or &
in the name. Instead we allow after the space of the return type an
optional * or & before accepting the function name.
Each function with a body should have a function comment header directly
above it. Modified the lint script to check for its presence and
validate that it meeds certain requirements.
Updated existing tests to include the funciton header so they don't
generate warnings for its absence. Also updated the test description as
the line numbers of the deliberate errors have changed.
Added new tests for the different ways the function header can be wrong
Since we can't in general (without type analysis I think) tell the
difference between a bit shift operator << and a stream manipulator <<
we don't warn about it. In some instances we can tell if it is a stream
manipulator so we check for spaces there. I've added a known bug
operator-spacing3 that would be the perfect report of errors.
This fixes previous bug with brackets in comments (in a cleaner and more
consistent way) as well as addressing the bug to do with brackets in
comments. Weirdly, it was claiming to be using lines with strings
removed, but printing the line clearly shows that
`lines_without_raw_strings` still contains at least some strings.
To deal with splitting lines containing operators up, if the operator
starts the new line, we shouldn't require white space before it be
removed. Instead, we only check for white space on the left side of
operators if we've encountered some non-white-space characters that
line.
There are about 500 cases in the code where the operator starts the new
line and 250 where it ends the previous line so not practical to require
one over the other.
Removed most of the old lint if checking as they want braces on the same
line so was mostly the opposite of what we wanted (which is in fact much
simpler).
Removed the old check for if(...) { as this is already picked up by the
braces at the end of line checks.
Added additional tests for different ways the if statement can be wrong
or right.
When checking for spacing around operators, we need to be careful with
<, > since are also brackets around template types. In these cases, a
space after the > but not before is acceptable. The approach I've taken
is to find the matching opening angled bracket and inspect the contents
between them.
The linter was picking up that while(...); looks like an empty while
statement. However, unlike what the linter is expecting, we put while on
a separate line to the closing brace for a do...while statement. Instead
the linter now searches previous lines for a matching do statement. If
it finds a while before the do then it obviously isn't related to this
while.
In class declarations, it was previously warnining that the class
identifier didn't end with a t because there was a space between the end
of the identifier and the : (for inheritance). Now provides a warning
that this space shouldn't be present and doesn't warn about the
identifier.
The linter script has exceptions to exclude incorrect detection of C
style casts. Added the keyword catch to this list. Added a regression
test to verify this.
Hannes Steffenhagen