Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

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