Re: Raising our compiler requirements for 9.6

Andres Freund <andres(at)anarazel(dot)de> writes:
> On August 15, 2015 6:47:09 PM GMT+02:00, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> That gave me new respect for STATIC_IF_INLINE. While it does add
>> tedious work to the task of introducing a new batch of inline
>> functions, the work is completely mechanical. Anyone can write it;
>> anyone can review it; there's one correct way to write it. Header
>> surgery like
>> 0001-Don-t-include-low-level-locking-code-from-frontend-c.patch
>> requires expert design from scratch, and it (trivially) breaks builds
>> for a sample of non-core code. Let's return to STATIC_IF_INLINE and
>> convert fastgetattr() therewith. (A possible future line of inquiry is
>> to generate the STATIC_IF_INLINE transformation at build time, so the
>> handwritten headers can use C99 inlining directly as though it is
>> always available.)

> I'll respond in detail later. But wouldn't it be easy in this case to
> just ifndef FRONTEND things in this case?

I think that's missing Noah's point. Yeah, we'll probably always be able
to hack things to continue to work, but the key word there is "hack".
And if we don't have buildfarm coverage for compilers that are stupid
about inlining, we can expect to break the case regularly. (pademelon
won't last forever, though maybe by the time that box dies we'll figure
we no longer need to care about such compilers.)

I'm not especially in love with STATIC_IF_INLINE, but it did offer a
mechanical if tedious solution.

Realistically, with what we're doing now, we *have* broken things for
stupid-about-inlines compilers; because even if everything in the core
distribution builds, we've almost certainly created failures for
third-party modules that need to #include headers that no contrib
module includes.

Maybe we should just say "okay, we're raising the bar for 9.6: compilers
that don't elide unused static inlines need not apply". But I'd be
happier if we had a clear idea which those were. And if we go that route,
we ought to add a configure test checking it.

regards, tom lane