title: unused `static inline` functions generate warnings with `clang`
body: <p>When using <code>gcc</code> or <code>clang</code>, it's generally a good idea to enable a number of warnings, and a first batch of warnings is generally provided by <code>-Wall</code>.
  This batch is pretty large, and includes the specific warning <code>-Wunused-function</code>.</p>
  
  <p>Now, <code>-Wunused-function</code> is useful to detect <code>static</code> functions which are no longer invoked, meaning they are useless, and should therefore preferably be removed from source code.
  When applying a "zero-warning" policy, it's no longer "preferable", but downright compulsory.</p>
  
  <p>For performance reasons, some functions may be defined directly into header files <code>*.h</code>, so that they can be inlined at compile time (disregarding any kind of LTO magic). Such functions are generally declared and defined as <code>static inline</code>.
  In the past, such functions would probably have been defined as macros instead, but it's considered better to make them <code>static inline</code> functions instead, whenever applicable (no funny type issue).</p>
  
  <p>OK, so now we have a bunch of functions defined directly into header files, for performance reasons. A unit including such a header file is under no obligation to use all its declared symbols. Therefore, a <code>static inline</code> function defined in a header file may reasonably not be invoked.</p>
  
  <p>For <code>gcc</code>, that's fine. <code>gcc</code> would flag an unused <code>static</code> function, but not an <code>inline static</code> one.
  For <code>clang</code> though, the outcome is different : <code>static inline</code> functions declared in headers trigger a <code>-Wunused-function</code> warning if a single unit does not invoke them. And it doesn't take a lot of flags to get there : <code>-Wall</code> is enough.</p>
  
  <p>A work-around is to introduce a compiler-specific extension, such as <code>__attribute__((unused))</code>, which explicitly states to the compiler that the function defined in the header may not necessarily be invoked by all its units.
  OK, but now, the code which used to be clean <code>C99</code> is including some form of specific compiler extension, adding to the weight of portability and maintenance.</p>
  
  <p>The question therefore is more about the logic of such a choice : why does <code>clang</code> selects to trigger a warning when a <code>static inline</code> function defined in a header is not invoked ? In which case is that a good idea ?</p>
  
  <p>And what does <code>clang</code> proposes to cover the relatively common case of inlined functions defined in header file, without requesting the usage of compiler extension ?</p>
  
  <p><em>edit</em> :
  After further investigation, it appears the question is incorrect.
  The warning is triggered <em>in the editor</em> (VSCode) using <code>clang</code> linter applying a selected list compilation flags (<code>-Wall</code>, etc.). 
  But when the source code is actually compiled with <code>clang</code> and with exactly the same list of flags, the "unused function" warning is not present. </p>
  
  <p>So far, the results visible in the editor used to be exactly the ones found at compilation time. It's the first time I witness a difference. </p>
  
  <p>So the problem seems related to the way the linter uses <code>clang</code> to produce its list of warnings. That's a much more complex and specific question.</p>
  
  <hr>
  
  <p>Note the <a href="https://stackoverflow.com/questions/59958785/unused-static-inline-functions-generate-warnings-with-clang#comment106068414_59958900">comment</a>:</p>
  
  <blockquote>
    <p>OK, sorry, this is actually different from expectation. It appears the warning is triggered <em>in the editor</em> using <code>clang</code> linter with selected compilation flags (<code>-Wall</code>, etc.). But when the source code is compiled with exactly the same flags, the "unused function" warning is actually not present. So far, the results visible in the editor used to be exactly the ones found at compilation time; it's the first time I witness a difference. So the problem seems related to the way the linter uses <code>clang</code> to produce its list of warnings. It seems to be a more complex question [than I realized].</p>
  </blockquote>