Lists: | pgsql-hackers |
---|
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Downsides of scanning all .o files for typedefs |
Date: | 2014-04-06 16:06:19 |
Message-ID: | 15199.1396800379@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
I'd been getting weird results for the last couple of days while
pgindent-ing various patches. I eventually realized that the cause
was that the current typedefs list marks "c", "string", and a few
other common words as typedefs. This seems pretty uncool. Further
investigation shows that the reason is that these names are used as
typedefs in a couple of the ecpg regression tests; which the old
find_typedefs code never picked up on, but the OS X implementation
does.
Now, it's actually rather pointless to collect typedef names from
the ecpg tests, since pgindent won't process files with .pgc
extensions anyway (and I doubt it would work well to try).
So we could either revise these test cases to use less-generic
typedef names, or we could just skip ecpg/test/ in find_typedefs.
For the moment I've got dromedary using the attached quick-hack patch
to do the latter. Any thoughts on the best long-term answer?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
dont-find-typedefs-in-ecpg-tests.patch | text/x-diff | 799 bytes |
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Downsides of scanning all .o files for typedefs |
Date: | 2014-04-06 19:44:32 |
Message-ID: | 5341AEA0.3020607@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 04/06/2014 12:06 PM, Tom Lane wrote:
> I'd been getting weird results for the last couple of days while
> pgindent-ing various patches. I eventually realized that the cause
> was that the current typedefs list marks "c", "string", and a few
> other common words as typedefs. This seems pretty uncool. Further
> investigation shows that the reason is that these names are used as
> typedefs in a couple of the ecpg regression tests; which the old
> find_typedefs code never picked up on, but the OS X implementation
> does.
>
> Now, it's actually rather pointless to collect typedef names from
> the ecpg tests, since pgindent won't process files with .pgc
> extensions anyway (and I doubt it would work well to try).
>
> So we could either revise these test cases to use less-generic
> typedef names, or we could just skip ecpg/test/ in find_typedefs.
> For the moment I've got dromedary using the attached quick-hack patch
> to do the latter. Any thoughts on the best long-term answer?
As you say we're not going to be indenting the .pgc files anyway, so
this seems like quite a reasonable solution.
cheers
andrew