Re: Preliminary results for proposed new pgindent implementation

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Piotr Stefaniak <postgres@piotr-stefaniak.me>
Date: 2017-05-19T18:54:54Z
Lists: pgsql-hackers

Attachments

I wrote:
> What I was just looking at is the possibility of absorbing struct
> tags ("xllist" in the above) as if they were typedef names.  In
> at least 95% of our usages, if a struct has a tag then the tag is
> also the struct's typedef name.  The reason this is interesting
> is that it looks like (on at least Linux and macOS) the debug info
> captures struct tags even when it misses the corresponding typedef.
> We could certainly create a coding rule that struct tags *must*
> match struct typedef names for our own code, but I'm not sure what
> violations of that convention might appear in system headers.

I did an experiment with seeing what would happen to the typedef list
if we included struct tags.  On my Linux box, that adds about 10%
more names (3343 instead of 3028).  A lot of them would be good to
have, but there are a lot of others that maybe not so much.  See
attached diff output.

I hesitate to suggest any rule as grotty as "take struct tags only
if they begin with an upper-case letter", but that would actually
work really well, looks like.

			regards, tom lane

Commits

  1. Manually un-break a few URLs that pgindent used to insist on splitting.

  2. Remove entab and associated detritus.

  3. Phase 3 of pgindent updates.

  4. Phase 2 of pgindent updates.

  5. Initial pgindent run with pg_bsd_indent version 2.0.

  6. Adjust pgindent script to use pg_bsd_indent 2.0.

  7. Final pgindent run with old pg_bsd_indent (version 1.3).