<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/80568>80568</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Reasoning about the poorly-defined behavior of function attributes across TUs
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          ryandurkoske
      </td>
    </tr>
</table>

<pre>
    Attributes attached to a function declaration, in a TU separate from the definition, don't do anything.  They don't throw no-unused-attribute errors either.  An error or warning not being thrown even with -Wall is a bug, likely occurring because attribute usage is statically checked and assumes the definition exists in the TU somewhere.  By mistake of the programmer or by his intention, it should not be assumed by the compiler that the declaration always has a definition in its TU.

A better language to reason about this behavior:

I suppose 3 categories for different types of attributes: caller attributes; definitional attributes; and link-time attributes. We segregate them based on when/where the attribute's consequence takes affect.  Naked is a great example of a compile-time, definitional attribute. always_inline is a caller's attribute (might be link time might be compile time. shouldnt matter.), and visibility or dllexport is a link time attribute.

Why this all matters:

 Suppose you're working with a general x64 asm library that you decide to integrate into a Clang C project.  You'd need a header of function declarations to define the ABI to call the functions from your C code.  Some of the function declarations are marked always_inline, and that should seemingly work because its a callers attribute.  Will it? No, it does not work.  All attributes of a function declaration are dropped unless its TU can see the definition.

Suppose your C wants to directly dllexport an asm function, you shouldn't need to be forced to modify someone elses asm library.  C should be powerful enough, s.t the dllexport attribute should just work when attached to the function delcaration in the header.  The consequence of the attribute is not processed until link-time, anyway. Attributes should be accumulated during unknown symbol resolution, and link-time attributes' consequences can be processed after all symbol resolution.  It wouldn't be difficult to implement such behavior.  All it requires is storing the attributes in the symbol table for all unknown symbols during compilation.  

Do I think we should change this undocumented behavior of attributes across TUs? No, for the sake of backwards compatibility.  We should add a new keywork like __linker_attribute__ or something prettier, you get it.  This way, attributes that cannot possibly be linker attributes can throw errors.  Naked attribute, for example, cannot be a link time attribute because it would modify the function body at compile time.

Caller-time function attributes should not need to be marked as __linker_attribute__ to work, because it wont apply to the definition across the TU.  Its effect is local to its TU.  It should work by default.  At this point, maybe by introducing another keyword so that errors can be more easily enforced.  __caller_attribute__((noinline)).

Its tough to reason about which category optnone would fall into.  Let's talk about that.  I believe it could be definitional or caller's, depending on where the definition is and what attribute keyword you use.

Regardless of whether or not you see a need for this, it should be documented somewhere, or at a bare minimum throw a no-unused-attributes error.  The attributes are dropped silently.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJx0V81u4zgSfhrlUojgluNOcvAhnUaAAIs5zPSgsaegRJYljilSwyLj1tsvipRsOZ29JLYskR_r-6kSMpvOEe2r3bdq9_0GU-x92IcJnU7h6PlIN63X0_4pxmDaFIkBY0TVk4boAeGQnIrGO9CkLAaUz1XzDMYBwo-_gWmUqwSH4AeIPYGmg3FmuU_Lv_sI2gO6KfbGdTXAj56m80-xD_4Ezt8ml5j0LS5YgELwgYFM7CnUAE-uXAIf4ITBGdeB8xFakk95HQf0Tg5OJvZw-xOtBcOA0KZO0FhzJDuBVyqFIM-0pDAxwWXPxNiRPMQRo1Fo7QSqJ3UkDeg0IHMaiD8cFeiX4chSFvlBCuMHOvUUqAb4NsFgOOKRwB_yDWPwXcBhoHyWdoLeyMOR3LnAEbj3yer5hPPGWm6WFZQfRmMpQOwxzmjODAHaE04MPcrhVzCNAxMZfvxdV5vv1eap_H2ClmKkABZdl-T80UMgZFmp9UnWNwwt9fhufKi2T-unX4HTOHom2ILCSJ0PhhgOPoA2hwMFchHiNBLL6c-V5mr7BFJfClcXv63wov3wkzBgjTveRjOsWOMafhIwdYE6EWPsaYAWmTR4B6eeXNW8ZDZypc7PVc09g_KO6d9EThEIRwx4OJCKNcAfKLRnBXWBMAL9wmG0mUZcKMhYstY_xV3PZLwZZ42jslo5d97-Ir2qeRhM12e25ZCQD3m-NG-Xr9azOFyEAYW6umoeBYMU6N2waY01cRJxaWvp1-hDLDtfFr4gXLP5s58K2-KdsjZ_IBz-mvmefKqa-0Bw8uEodsq2Q-jIUUALv77eAfIA1rQBw1SkOvkkUjU6q0w03-UAMS4HzrNoEJ7FIf8UEv6bd9HgSCwIPaEW2xw-zSaWRTMRheqnb69yReqdvy_PcAmsyacAz6C8Fp_-5YezQz9fHAPBgCGHwZrVpfT5hLNvmWgwrrNTLs85asR_iwB4LRP4aSSuYrV9gT_8nAHaE-cEkDUkAu3aEkWHn0HNSHXw40gakrPEPDsfFDrB9iHBrkSwIljKc0IXS2FNIBXttBIVukzxgkFgC8OzPHPAZ-KiFw0ffFDly-C1OUw5Jr0jIMtivItYaoDnpZItwehPFA7JAjmful624XrOvQuWs5XmB_9JXCqXM-CqtX3g2KqlcHOEF5mVXnUVEbM-LnuZQtAYvCLmXO5o7CWmijamE041rPrs5WyoVBqSxUgadMp9Kbmjk2bG09B6C4HY27TU9_-FYNXcr5FyZrqlFTI8SMqLF35buAZ4lVqdWWspx7dRycbsVAm-QbKck-rPzWDWpIkQ6N9kAnFpnj6UnrwGuNR23jxia7MkMqLrI_NSiZJ6OENci_S7h1eJKneE05lx1aOT_iUJlpz2KglkaZsz3useBKiCZ7EFX2wniDLMuWG3qI4nDJozGIxzuIpjz_uilmxydIIjTVlxMmvA25sQReHtvOXbm4SyyD4PQzAGitFILyjG6SiCiVl3huGEU2b8AjgnjEKXJeeZTWunpWFcddLMfpmtyhx17mer9lcOO3c1-TqvLKr8rFWsUqxoZfHxlZ1kpASBue5Ya-qec_oV_Z6fwt-8IUhW4bEEL39e1uiz1eUUVyhdBBxHOy2uX41DM_tlZMsOYKDc_EXE1iu0WfplZMoOmaGVSJ9kMUxW-Hqap6TRGxcFxIBTS3KPcTF4nZTQjc7LMDurRAP7wug86s6OHXwgIGRjJyBXQrMGeHsrbWN97Kp5qJoH55c-9Fg1j1e1fs3Rnbr-t6Hu1BvVLyPbBH6MTqK48HrIs7OLvgb4D8U8qkS0x_NAiHLoV2jJGnrPpVZLoF0NQj6spp0yJo3ktBSjzGbhYyvKg4rTcJLCXKS3lExckvhaUH9Sh0HnLucPsmgusg9ZQrkfEWV_kp7tbfh6yhbYl7Q4T-9ykwRUlJeI3P2NM0MaZmfhZ-8tXNice8c6bFY9mY0lF-1U3-j9Vj9uH_GG9l_uN_ebzZdmu7vp96i-tGp7p9V2d9fuHnbt5oH0_cPd3WPzeIeb3Y3ZN5vmbtNsts12s9nu6sederz7etih2pCi-011t6EBja2tfR9qH7obw5xo_7DZfX24sdiS5fxq2DSSXPnHqmnkTTHs5ZnbNnVc3W2svNxcVokmWtr_mbWURT1LQtq0D3a6LQPYdeh-5vNL-t6kYPd9jGMeNpuXqnnpTOxTWys_VM2L7D3_u51Hw6p5yYi5al7yif4XAAD__1D3Vy8">