test suite
This change does the following:
- Introduces symmetry in the test inputs/outputs by adding the exit
code to the files. This simplified the test driver notably by
requiring less filename/test name manipulation.
- Adds a test driver for the testcases added in r313544, patterned
after bin/sh/tests/functional_test.sh . The driver calls indent as
noted in r313544, with an exception: The $FreeBSD$ RCS keyword's
expansion is reindented with indent, which means that the output
differs from the expected output. Thus, all lines with $FreeBSD$
in them are deleted on the fly, both in the input file and the
output file.
The test inputs/outputs are copied to the kyua sandbox before the
test is run as the pathing in some of the files relies on pathing
normalized to the current directory (copying the files is the
easiest way to resolve the issue).
Approved by: pstef (maintainer)
Reviewed by: pstef
X-MFC with: r313544
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D9682
These examples show expected behavior of indent(1). They are meant to be used
together with a regression test mechanism, either Kyua, a Makefile or perhaps
something else. The mechanism should in essence do this:
indent -P${test}.pro < ${test}.0 > ${test}.0.run
and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit
status isn't 0, the test failed.
* ${test}.pro is an indent(1) profile: a list of options passed through a file.
The program doesn't complain if the file doesn't exist.
* ${test}.0 is a C source file which acts as input for indent(1). It doesn't
have to have any particular formatting, since it's the output that matters.
* ${test}.0.stdout contains expected output. It doesn't have to be formatted in
Kernel Normal Form as the point of the tests is to check for regressions in
the program and not to check that it always produces KNF.
Reviewed by: ngie
Approved by: pfg (mentor)
Differential Revision: https://reviews.freebsd.org/D9007
Without this change, indent(1) would only look to load options from ~/.indent.pro if it's there and -npro wasn't used on the command line. This option lets the user set their own path to the file.
Approved by: pfg (mentor)
Differential Revision: https://reviews.freebsd.org/D9010
ps.paren_indents:
When ps.paren_level was 0, this was accessing paren_indents[-1].
in_buffer:
This fragment checks if "*/" was read, but there's no guarantee that there
is more than one byte in the array (actually, this happens frequently for
the "{" in things like "int main(void) {").
Submitted by: Piotr Stefaniak
When special else-if processing is enabled (-ei), we can assume "else if"
and "if" to be equivalent for indentation purposes.
This reduction saves a lot of stack space in case of a long "if-else-if
... else-if" sequence; with this change,
Postgres/src/bin/psql/tab-complete.c as of 9.6beta3
requires minimum of the stack length to be 31 instead of 444.
Submitted by: Piotr Sephaniak
Teach indent(1) about storage-class specifiers. Don't assume
"in_parameter_declaration" state if "in_decl" hasn't been set. Don't set
"in_decl" for storage-class specifiers.
That set of changes helps with recognizing the difference between file
scope declarations like this:
static LIST_HEAD(, alq) ald_active;
static int ald_shuttingdown = 0;
struct thread *ald_thread;
and old style function declarators like this:
static int
do_execve(td, args, mac_p)
struct thread *td;
struct image_args *args;
struct mac *mac_p;
{
Unfortunately, at the same time this change makes indent(1) require
explicit int in declarations like "static a;", in order to understand that
it's part of a declaration. On the other hand, declarations like in the
first example are no longer indented as if ald_shuttingdown and ald_thread
were parameters of a function named LIST_HEAD.
Submitted by: Piotr Stefaniak
pr_comment() did avoid adding surplus space character when a comment
contained it at the end. Now it's also paying attention to tabs.
Taken from: Piotr Stefaniak
indent.c has a special loop that stores tokens from between an if () and
the next statement into a buffer. The loop ignored all newlines, but that
resulted in not calling dump_line() when it was needed to produce the
final line of the buffered up comment.
Taken from: Piotr Stefaniak
Work-around a somewhat complex interaction within the code. From
Piotr's commit [1]:
When pr_comment() calls dump_line() for the first line of a multiline
comment, it doesn't include any indentation - it starts with the "/*".
This is consistent for both boxed and not boxed comments. Where the logic
diverges is in how it treats the rest of the lines of the comment. For box
comments indent assumes that it must not change anything, so lines are
dumped as they were, including the indentation where it exists. For the
rest of comments, it will first remove the indentation to store plain text
of the comment and then add it again where indent thinks it's appropriate
-- this is part of comment re-indenting process.
For continuations of multi-line comments, the code that handles comments
in dump_line() will use pad_output() to create indentation from the
beginning of the line (what indent calls the first column) and then write
string pointed by s_com afterwards. But if it's a box comment, the string
will include original indentation, unless it's the first line of the
comment. This is why tab characters from s_com have to be considered when
calculating how much padding is needed and the "while (*com_st == '\t')
com_st++, target += 8;" does that.
In dump_line(), /target/ is initially set to ps.com_col, so it always
assumes that indentation needs to be produced in this function, regardless
of which line of a box comment it is. But for the first line of a box
comment it is not true, so pr_comment() signals it by setting
ps.n_comment_delta, the negative comment delta, to a negative number which
is then added to /target/ in dump_line() on all lines except the first
one, so that the function produces adequate indentation in this special
case.
The bug was in how that negative offset was calculated: pr_comment() used
count_spaces() on in_buffer, which pr_comment() expected to contain
non-null terminated sequence of characters, originating from whatever
originally was on the left side of the comment. Understanding that
count_spaces() requires a string, pr_comment() temporarily set buf_ptr[-2]
to 0 in hope that it would nul-terminate the right thing in in_buffer and
calling count_spaces() would be safe and do the expected thing. This was
false whenever buf_ptr would point into save_com, an entirely different
char array than in_buffer.
The short-term fix is to recognize whether buf_ptr points into in_buffer
or save_com.
Reference:
[1]
ea486a2aa3
Taken from: Piotr Stefaniak
indent(1) treated the "L" in "L'a'" as if it were an identifier and forced
a space character after it, breaking valid code.
PR: 143090
MFC after: 2 weeks
Multi-line comments are always block comments in KNF. Restore properly,
handling the case when a long one-liner gets wrapped and becomes a
multi-line comment.
Obtained from: Piotr Stefaniak
This is not actually documented or even implied in style(9). Make the change
to match convention. Someone should document this convention in style(9).
Reported by: jhb
Sponsored by: EMC Dell Isilon
This is a nice and trivial program for sandboxing. One input file, one
output file.
Reviewed by: pfg
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D7920
Coverity correctly reported that it's impossible for /comparison/ to be 0
here, because the only way for the for loop to end is by /comparison/
being < 0.
Fortunately the consequences of this bug weren't severe; for duplicated
entries in the typedef names file it would unnecessarily duplicate strings
with strdup(), but pointers to those would replace existing ones. So this
was a memory leak at worst.
CID: 1361477
Obtained from: Piotr Stephaniak
Shift the responsibility of allocating memory for the string duplicate
from the caller (set_option, add_typedefs_from_file) to the callee
(add_typename) as it has more knowledge about when the duplication
actually needs to occur.
Taken from: Piotr Stefaniak
Add -sac (space after cast) and -nsac options.
These control whether space character is put after a cast operator or not.
Default is -nsac.
Add -U option for providing a file containing list of types.
This is needed for properly deciding which asterisks denote unary
operation and which denote binary.
These come from PostgreSQL.
Reference:
84b00e3d4649c52cf383
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
For now maintain the local style in this file.
Reviewed by: jilles
Reference:
9099a9f17b
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
clang-analyzer complained that eqin() sets file-scoped pointer param_start
to point into char buffer defined in scan_profile(), and once
scan_profile() exits, param_start is a "dangling reference". param_start
was never used afterwards, but it's cleaner to move it to set_option()
which is the only branch where param_start is needed.
Reference:
ab0e44e5da
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
It's pr_comment.c that should decide whether to put a "star comment
continuation" or not. This duplicates code a bit, but it simplifies
pr_comment() at the same time since pr_comment() no longer has to "signal"
whether a star continuation is needed or not.
This change requires indent(1) to not wrap comment lines that lack a blank
character, but I think it's for the better if you look at cases when that
happens (mostly long URIs and file system paths, which arguably shouldn't
be wrapped).
It also fixes two bugs:
1. Cases where asterisk is a part of the comment's content (like in "*we*
are the champions") and happens to appear at the beginning of the line,
misleading dump_line() into thinking that this is part of the star comment
continuation, leading to misalignment.
2. Cases where blank starred lines had three too many characters on the
line when wrapped.
Reference:
3b41ee78aa
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
After a blank line was printed (to separate paragraphs in comments), the
next line was sometimes wrapped to the column at which the previous
non-empty line ended. The fix is to reset the last blank pointer (last_bl)
on newline.
References:
345663c07a
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
Modify count_spaces() to take a third parameter "end" that will make the
function return when the end is reached. This lets the caller pass a
pointer to non nul-terminated sequence of characters. Rename
count_spaces() to count_spaces_until() and reinstate count_spaces(), this
time based on count_spaces_until().
Use count_spaces_until() to recalculate current column when going through
a comment just before the fragment which decides if current line of the
comment should be wrapped. This move simplifies this code by eliminating
the need for keeping the column counter up to date every time e_com is
advanced and also reduces spread of code that has to know how many columns
a tab will produce.
Deduplicate code that decided if a comment needs a blank line at the top.
References:
d9fa3b481527185b4b33
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
The original indent(1) described unix-style comments as similar to box
comments, except the first non-blank character on each line is lined up
with the '*' of the "/*" which appears on a line by itself.
The code has been turned off for ages and -sc/-nsc make it even
less relevant.
Reference:
89c5fe2c56
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
Also increase the stack size still keeping a conservative value of 256.
This is based on a similar changes done for PostgreSQL which instead
uses a stack size of 1000.
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak (with changes)
This fixes a very visible issue that may be hidden by some indent.pro
settings as in the example from FreeBSD's /usr/share.
From Piotr's log:
____
To prevent losing tabs from indentation in declarations, FreeBSD indent's
r125624 added code for the most common case when it's an identifier that
is indented, but didn't do anything with the original code that did the
same for any other cases. The other cases are: lparens (function pointer
declaration), asterisks (pointer declaration), stray semicolons, and
commas leading identifiers instead of trailing them.
Use the code added in r125624 (and improved in later commits) to write a
new function indent_declaration() and use it in all places that meant to
indent declarations. In order to indent only once per line, reuse existing
ps.dumped_decl_indent variable that was only used when formatting for
troff (-troff) until now.
____
Reference:
ddd263db2a
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
strchr(3) returns a pointer not a boolean.
Attempt to make the style somewhat more ocnsistent with what indent
had before recent changes.
Pointed out by: bde
Remove the excessive braces from r303485 and align the comments to the
right as done in the rest of the code. This is not nice but there is no
clear way to make it nice (and KNF).
Pointed out by: bde
Actually this just brings back r303487 with the correct commit log.
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Obtained from: Piotr Stefaniak
This piece of code removed tabs and space characters from after colons
that follow labels by decrementing the e_lab (end of label) "pointer"
which is later used to calculate the width of the string that fprintf()
puts into "output". But pad_output() gets the length from the actual
string, so it miscalculated what the current column is.
Fixed by putting a string terminator at the e_lab "pointer".
Differential Revision: https://reviews.freebsd.org/D6966
(Partial)
Obtained from: Piotr Stefaniak
indent(1) simply wasn't taught that "else" may be followed by a comment
without any opening brace anywhere on the line, so it was very confused
in such cases.
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Obtained from: Piotr Stefaniak
