If the --fix-inplace option for TABSTOP encounters a sitation with several
spaces (but less than 8) at the end of an indentation, it will assume that there
are extra indentation and align back to the nearest tabstop instead of the next.
This might go undetected in a "full" checkpatch --fix-inplace run, as this
potential new error will be handled by SUSPECT_CODE_INDENT further down in the
script. The code for TABSTOP have limited "knowledge" of the previous line.
Adding complexity when it is taken care of later anyway is maybe unnecessary/undesired.
As a simple heuristics just use a "natural" rounding algorithm and round
up for 4 spaces or more.
There's an example in line 108 in net/rds/ib_recv.c with indentation TAB + 7
spaces where the correct would have been an additional TAB. With only TABSTOP
enabled, checkpatch will fix this to a single TAB, which is visually worse IMO.
Reported-by: Håkon Bugge <[email protected]>
Signed-off-by: Knut Omang <[email protected]>
Reviewed-by: Håkon Bugge <[email protected]>
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 387292f..c17178e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3061,7 +3061,7 @@ sub process {
if (WARN("TABSTOP",
"Statements should start on a tabstop\n" . $herecurr) &&
$fix) {
- $fixed[$fixlinenr] =~ s@(^\+\t+) +@$1 . "\t" x ($indent/8)@e;
+ $fixed[$fixlinenr] =~ s@(^\+\t+) +@$1 . "\t" x (($indent+4)/8)@e;
}
}
}
--
git-series 0.9.1
From 1584257753485837927@xxx Thu Nov 16 20:58:50 +0000 2017
X-GM-THRID: 1583646864494093955
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread