Consistently use "static QINLINE" for inline C code #884
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
The portable idiom for type-safe macro-like constructs in C is to use
"static inline" where C99 inline is supported, or "static __inline"
on compilers that implement that keyword as a compiler-specific
extension (at least gcc, clang and MSVC do), falling back to just
"static" as a last resort on terrible compilers from the distant past.
Using "static QINLINE" everywhere means there is no point in defining
QINLINE to "static inline" on clang, so stop doing that; QINLINE now
consistently expands to Standard C/C++ inline, or __inline on MSVC,
or to nothing if we don't know how to inline functions on this
compiler.
This silences warnings about redundant qualifiers (static static inline)
for all the functions that were already inline.
There are a couple of uses of non-static QINLINE in C++ code; I've
left those intact, since inline has different (more useful)
semantics in C++, and as far as I'm aware all reasonable C++ compilers
implement it correctly.
As requested by @xycaleth on #869.