Re: Re: [COMMITTERS] pgsql: Add macros wrapping all usage of gcc's __attribute__.

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2015-03-25 19:11:06 -0400, Tom Lane wrote:
>> I think this is a bad idea, because it's going to look like heck after
>> pgindent gets through with it. Do we actually need decoration on the
>> function definitions?

> Hm, I guess it should not look any worse than before?

It does, because pgindent treats "pg_attribute_noreturn" differently
than it treated "__attribute__((noreturn))". Before you'd end up
with something like

void
__attribute__((noreturn))
plpgsql_yyerror(const char *message)
{

pgindent forced the __attribute__(()) bit onto its own line, whether you
wrote it that way or not, but it doesn't look *too* awful. But now that
becomes:

void
pg_attribute_noreturn
plpgsql_yyerror(const char *message)
{

The best you can get is to manually put the noreturn back onto the
"void" line, but you still end up with:

void pg_attribute_noreturn
plpgsql_yyerror(const char *message)
{

So this is just ugly. Maybe we could teach pgindent not to do that,
but I'm doubtful.

> ... That said, I see little reason
> to add the noreturn thingy to the definition and not the declaration for
> those. It actually looks to me like there's a declaration for
> replication_yyerror, but a plain yyerror is used instead in repl_scanner.l?

Right.

Also, even in the context of extern declarations, it seems to be a lot
easier to get pgindent not to mess with your layout if
"pg_attribute_noreturn" is replaced with "pg_attribute_noreturn()".
I see no particular reason not to add parens to the macro, do you?

Being the one complaining, I'll go do the legwork to clean this up.

regards, tom lane