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

    <tr>
        <th>Summary</th>
        <td>
            [Clang] User-relevant warnings in system headers
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            clang
      </td>
    </tr>

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

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

<pre>
    We silence warnings in system headers on the basis that such warnings are not user-actionable. In practice, using -Wsystem-headers can be fairly noisy.

https://godbolt.org/z/eaxen4vob

However, we find that this silences... too much.

* Warnings are silenced when an expression involves a user-provided type or expression that is either invoked or converted
    - https://compiler-explorer.com/z/6Ma56fjYf
    - https://godbolt.org/z/GnTsrnYfo ( #141791 )
    - #141103

* Depreciation warnings are not emitted for standard types instantiated by the standard library (#134425) 

This boils down to "happens in system headers" not always being a good heuristic for "is user relevant".

The solutions I thought about are
   
   - Be a lot more aggressive about showing warnings in headers on a case-by-case basis and expect implementers not to trigger any of these warnings.
   - Give implementers a pragma/attribute to show warnings in a region of code  - this would be used every time library code could involve a user-provided type/expression
   - In the front end, provides an API to show warnings in system headers based on multiple locations, rather than the location of the warning itself.  We would then inspect types and expressions to determine whether they involve user-defined types.
   - Inspect the instantiation stack and show warnings if parts of the stack are in user code
   - When emitting warnings, wait until we have collected all the notes and produce warnings if any of the notes are in user code. This seems particularly involved/inefficient.
   - A new attribute like `[[deprecated]]` but never silenced

Instantiation stacks make for a not-so-good heuristic:
   - Some warnings in system headers might be relevant even if no instantiation happens
   - Some warnings in system headers might be caused by instantiation from user code and still be completely irrelevant.

A simplification of looking at instantiation stacks is that if a warning is produced in a system header after we have completed the initial parse of that header, we display it.

I suspect we might want to land on a mix of some of these ideas.








</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJyUVl2P4joS_TXhpQQKBprmgQdmWj3Lw0or7axa81iJK4mnHTuyK9Dsr78qJwH6Y650JQRSKFedqjrnOBijqR3RPtt8yzZPM-y58WFf-rBybNys8PqyfyGIxpIrCc4YnHF1BOMgXiJTCw2hphDBO-CGoMBoInCDDLEvm9sJDATOM_SRwhxLNt5hYWkBRwddkAclZeo79NG4GuYvQ_r5lL5EBwVBhSbYCzhv4mWR5YcsPzTMXcxWh0w9Z-q59rrwlhc-1Jl6_n-mngnfyK1PvhjC_-XPdKIgpc4ElXF6QMuNiVOfcbFYAHsPbV82Y5lMHeDlvpkxVsO5IQfogN66QDEa78C4k7cnioBDv13wJ6NJA186Ah_uY1N1E4EMNxTS0VfSElR6d6LApLP8AAAwh_e9lr7tjKUwp7fO-kBhUfp27Prh37h5qH7_qv5w9vOcfrifMbhflYdMPUKmVsv1crtbQqZ21xzD02W-us3kibpApUFZ6OdtU2uYSUPlA0RGpzEMQxAKyQM2KP8Xl8Sea4g1RcBwEShSc7Veq02mdjDU_Sm7KryxEbQ_O2DBrBrsOnJfcDNTKoFBe8ZLhIKEYQi19xoa6oOJbMoEMVPKxLQyCGTphI4zpRZTVYLobS-dRjgCN76vGwYsfM_S8TCm4XsO3wgQrGdofSDAuk4LP9EYHxt_Fhz3krrTEkKJkebFZS6_o6zQaWEOlQym7Sy15FjipTn2wMHUNQVAdwFfyUDjTbKLCdcPwfDuOIoA6xYz9YzMwRQ9k-QTiO_wIQSqZc--gtJrknRJN2ffWy367CNpEH1dgE1L1z2m6DJFjdr4Uhoi16syJsDHwVmq4B0DOS3SHU_JSODwn-OXaD8YVIGCzTtoe8umswTWl4m2UTIGTPLjBody05_jJKfMYDiSrRYALzS2zaJ_42Lay8DtcVFjI1HgaWIKrXEkfjGWost1GmkWmirjxlHcFnacUjd0JxqBFhnL11TsQ_MVdBg4TtjHuCDnB3bLPqb8L4I_CfWej8kg0TD0jo0Vr2zwJDu0lkqRLFqbkjvPY8dd8Lp_d0tUd1ycAj-gWEBScyRqY0Jtyt6imPw4Gp2pZ-OoqkxpyPF1LAdwdIYbYa15Jcge8nSVfdPJlsRbss2TfB5yKHoGJ-S8evcg7OPnoUZo8ZWSJ6AAn0c_f-8X4qQjkv_69m-vxtaITRR09RRRiJPpOP9ho6OH_ePMJSblFZcP-arg29usB6qwsTad8WICTDLqMEEbve4AUSzCVOamAuv9a3JO_oqGEaZ7X7Z-k0ucaKEHB3nXAWDFFO7INSDSI9cNG7RCikgDiZDHg-P1rU3sLF7ATLiPEPtBLWcap3OWgbMHK80nZ23Nm6SLMtyrTxpNGKe7_tNnpvcrvVvtcEb75Xb9uMk3ar2ZNfsd0RY3mOfqscg1bfPtw3alH1cPq81y-fC4mZm9ypWE7_LtZp1vFmu1Vfl6q5crWq7z1TZb59SisQtrT63cxzMTY0_75Xq5yx9nFguyMb2gKVVadHWmlLyrhb0cmBd9HbN1bk3keEvBhm16q_ueTmye4H9iMFcC_plTsz7Y_Yd3BcNNX4wvF1Ji_BHv_k0li0AFcszU84j6tFd_BQAA__8Rb5T6">