Re: Downsides of scanning all .o files for typedefs
От | Andrew Dunstan |
---|---|
Тема | Re: Downsides of scanning all .o files for typedefs |
Дата | |
Msg-id | 5341AEA0.3020607@dunslane.net обсуждение исходный текст |
Ответ на | Downsides of scanning all .o files for typedefs (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: