On 2015-07-01 16:33:24 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > At the very least I think we should start to rely on 'static inline's
> > working. There is not, and hasn't been for a while, any buildfarm animal
> > that does not support it
>
> pademelon doesn't.
Oh. I'd gone through all the animals somewhere in the middle of the 9.5
cycle. pademelon was either dormant or not yet reincarnated back then.
I'll go through all again then. Interesting that anole's compiler
supports inlines.
> Also, I think there are some other non-gcc animals that nominally allow
> "static inline" but will generate warnings when such functions are
> unreferenced in a particular compile (that's what the "quiet inline"
> configure test is about). That would be hugely annoying for development,
> though maybe we don't care too much if it's only a build target.
I know that 4c8aa8b5aea1e032f569222d4b6c1019e84622dc "fixed" that test
on a number of older platforms. Apparently even 10+ years ago some
compiler authors added the smarts to recognize whether static inlines
where declared in a header (don't warn) or in a .c file (warn).
> I'm not against requiring static inline; it would be a huge improvement
> really. But we should not fool ourselves that this comes at zero
> compatibility cost.
It's not zero, but I think it's quite small.
> > The list of features, in the order of perceived importance, that might
> > be worthwhile thinking about are:
> > * static inline
> > * variadic macros
> > * designated initializers (e.g. somestruct foo = { .bar = 3 } )
> > * // style comments (I don't care, but it comes up often enough ...)
>
> Of these I think only the first is really worth breaking portability
> for.
If variadic macros, or even designated initializers, were supported by
the same set of animals in the buildfarm I'd happily use it, but they're
unfortunately not...
