I've now done a round of comparisons of results of our old indent
with your current version. There's still one serious bug in the latter:
it continues to misformat enum typedefs, for instance
*************** PG_FUNCTION_INFO_V1(pg_prewarm);
*** 33,40 ****
typedef enum
{
PREWARM_PREFETCH,
! PREWARM_READ,
! PREWARM_BUFFER
} PrewarmType;
static char blockbuffer[BLCKSZ];
--- 33,40 ----
typedef enum
{
PREWARM_PREFETCH,
! PREWARM_READ,
! PREWARM_BUFFER
} PrewarmType;
static char blockbuffer[BLCKSZ];
I spent some time trying to diagnose that, and what I found is that
while it's scanning the enum list, ps.in_decl is false, which causes
dump_line() to set ps.ind_stmt to true after the first line, which
causes later calls of compute_code_target() to add continuation_indent.
I was able to make the problem go away by making this change, which
reverts a change you'd apparently made since the old version of indent:
diff -ru /home/postgres/freebsd_indent/indent.c freebsd_indent/indent.c
--- /home/postgres/freebsd_indent/indent.c 2017-06-13 11:53:59.474524563
-0400
+++ freebsd_indent/indent.c 2017-06-13 15:51:23.590319885 -0400
@@ -944,7 +944,7 @@
}
ps.in_or_st = true; /* this might be a structure or initialization
* declaration */
- ps.in_decl = ps.decl_on_line = ps.last_token != type_def;
+ ps.in_decl = ps.decl_on_line = true;
if ( /* !ps.in_or_st && */ ps.dec_nest <= 0)
ps.just_saw_decl = 2;
prefix_blankline_requested = 0;
This also undoes a tendency of the new version to want to insert blank
lines that weren't there before inside struct declarations, eg
*** a/contrib/btree_gist/btree_macaddr8.c
--- b/contrib/btree_gist/btree_macaddr8.c
*************** typedef struct
*** 12,17 ****
--- 12,18 ----
{
macaddr8 lower;
macaddr8 upper;
+
/* make struct size = sizeof(gbtreekey16) */
} mac8KEY;
While I would not necessarily have quibbled with the addition of those
blank lines, I'm just as happy not to have them forced on us. I could
not find any places where reverting this change made the results worse,
so I'm unclear on why you made it.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
