Rely on inline functions even if that causes warnings in older compilers.

So far we have worked around the fact that some very old compilers do
not support 'inline' functions by only using inline functions
conditionally (or not at all). Since such compilers are very rare by
now, we have decided to rely on inline functions from 9.6 onwards.

To avoid breaking these old compilers inline is defined away when not
supported. That'll cause "function x defined but not used" type of
warnings, but since nobody develops on such compilers anymore that's
ok.

This change in policy will allow us to more easily employ inline
functions.

I chose to remove code previously conditional on PG_USE_INLINE as it
seemed confusing to have code dependent on a define that's always
defined.

Blacklisting of compilers, like in c53f73879f, now has to be done
differently. A platform template can define PG_FORCE_DISABLE_INLINE to
force inline to be defined empty.

Discussion: 20150701161447.GB30708@awork2.anarazel.de

1 files changed, 0 insertions, 18 deletions

diff --git a/config/test_quiet_include.h b/config/test_quiet_include.h
deleted file mode 100644
index 732b23149e9..00000000000
--- a/config/test_quiet_include.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- * For the raison d'etre of this file, check the comment above the definition
- * of the PGAC_C_INLINE macro in config/c-compiler.m4.
- */
-static inline int
-fun()
-{
-	return 0;
-}
-
-/*
- * "IBM XL C/C++ for AIX, V12.1" miscompiles, for 32-bit, some inline
- * expansions of ginCompareItemPointers() "long long" arithmetic.  To take
- * advantage of inlining, build a 64-bit PostgreSQL.
- */
-#if defined(__ILP32__) && defined(__IBMC__)
-#error "known inlining bug"
-#endif