On 2019-11-12 15:58:07 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > So perhaps we ought to rename pg_attribute_noreturn() to pg_noreturn(),
> > add a __declspec(noreturn) version, and move the existing uses to it.
>
> > I'm inclined to also drop the parentheses at the same time (i.e
> > pg_noreturn rather than pg_noreturn()) - it seems easier to mentally
> > parse the code that way.
>
> I guess my big question about that is whether pgindent will make a
> hash of it.
If one writes 'pg_noreturn void', rather than 'void pg_noreturn', then
there's only one place where pgindent changes something in a somewhat
weird way. For tablesync.c, it indents the pg_noreturn for
finish_sync_worker(). But only due to being on a separate newline, which
seems unnecessary…
With 'void pg_noreturn', a few prototypes in headers get indented more
than pretty, e.g. in pg_upgrade.h it turns
void pg_noreturn pg_fatal(const char *fmt,...) pg_attribute_printf(1, 2);
into
void pg_noreturn pg_fatal(const char *fmt,...) pg_attribute_printf(1, 2);
I'm a bit confused as to why pg_upgrade.h doesn't use 'extern' for
function declarations? Not that it's really related, except for the
'extern' otherwise hiding the effect of pgindent not liking 'void
pg_noreturn'…
I don't see a reason not to go for 'pg_noreturn void'?
> One idea is to merge it with the "void" result type that such
> a function would presumably have, along the lines of
>
> #define pg_noreturn void __declspec(noreturn)
> ...
> extern pg_noreturn proc_exit(int);
> and if necessary, we could strongarm pgindent into believing
> that pg_noreturn is a typedef.
Yea, that'd be an alternative. But since not necessary, I'd not go
there?
Greetings,
Andres Freund
