[prev in list] [next in list] [prev in thread] [next in thread] 

List:       llvm-bugs
Subject:    [llvm-bugs] [Bug 55776] `/showIncludes` implicit dependency scanning sporadically broken with clang-
From:       LLVM Bugs via llvm-bugs <llvm-bugs () lists ! llvm ! org>
Date:       2022-05-30 13:04:20
Message-ID: 20220530130420.df6f1e8b8b3bd8cb () email ! llvm ! org
[Download RAW message or body]

[Attachment #2 (text/html)]

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

    <tr>
        <th>Summary</th>
        <td>
            `/showIncludes` implicit dependency scanning sporadically broken with \
clang-cl (and Ninja) due to mixed output  </td>
    </tr>

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

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

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

<pre>
    Cross posted this issue with Ninja in ninja-build/ninja#2138.

From what I can tell clang-cl (14.0) currently outputs regular diagnostics to \
`stderr` and `/showIncludes` based `Note: including file:` notes to `stdout` (`cl` on \
the other hand outputs both to `stdout` which is why there this issue does not \
exist).

This is somewhat hard to reproduce and seems to depend on independent buffering and \
flushing of the two streams and the fact that Ninja currently merges both streams \
into one before parsing `/showIncludes` based notes for preprocessor included files.

When the mixing of the two streams happens at inopportune times this for me results \
in `/showIncludes` notes leaking to the console (meaning they at that point do not \
contribute to the list of implicit header dependencies either) or generation of \
non-existing header paths (where part of the path is actually a diagnostic that ended \
up at the end of the note) which I&apos;ve only indirectly noticed due to ninja \
generated `path too long` errors.

The issue seems to get further exacerbated by e.g. ANSI colored diagnostic \
(-fansi-escape-codes), CMake / CTest launchers and sccache (which capture and forward \
stderr/stdout) presumably because there may further influence when and how the two \
output streams are mixed.

A fix presumably would involve parsing `/showIncludes` notes only from the unmerged \
streams independently (or just `stderr`) or clang-cl outputting both diagnostics and \
`/showIncludes` notes to `stdout` (like `cl`does).

Not sure which is easier or more realistic.
</pre>
<img width="1px" height="1px" alt="" \
src="http://email.email.llvm.org/o/eJyFVU1v6zYQ_DXyhbBhy3ZiH3xI8xAgh-bSB_RMkSuJCUUK_Ij \
j_vrOUrbjvDYtYMik-LGzszOrxuvT4TH4GMXoYyItUm-iMDFmEkeTevFi3KsUxgnHg3mTjdVV_VRmVb2uV-vdo \
lr-qJYP0_Mp-EEce5nEs1DSiUTWCmWl6-bKiqrerTaLZVXvhcohkEv2JHxOY05RBOqylUFoIzsHNEZFkbyo7pY \
xaQoBAyGd5hdAEHt_fHbKZk2RVxoZqay9-ETV-gGYedG4TrTG8hve5bB4cytC81vAwp-yPPbA3JPweATRc7wLv \
gbv_nH02BvVgzAMTnww0C2F2iMaYgr6MDEh7S9c_Zw2iugHKpT1MmiOEGgMXmdFJd9INBTMmkZiPA65TWMQKJr \
cthQ4T97c2hx7nvi25JGOXsQUSOIKXud3rVQJAwScqvtZioFCR-dML6eMQ2jvSDTUeqQ3yhA5wH-VYaIZ28VYc \
lEUIyZTSbDOFYlfuPizp4n4wXx8A7-XI3JGGgkX-XH0IWXASmbgkjKXHHAg0BezTYz8G5ATPEvyjUMhPQ6lvIv \
eEothIOnKSk8nDle4Gj2YQEVLPbE5BdPkRJfjFgVm1GYYrVEGxSQJ1YpLoZRBSDIsEZY_kHbkKMhkUE-cc97Ni \
0o48PnsKFMfGdCxCAvMpwsxvMTaQSmztCidvPHNBJjDapHHKQMSRTvTaSaAUUzqfa7q-3dI3uEaKMsEUiwGbDI \
KN-hckiyWv4CerFZAJO-F9a5jYuFSH-IvIqezGa467iiJNofiMPqQikJTbmxOghbdQjy8_IHm4S3Upm-zAhHzV \
rpo5hSVHGmuPBe03lf1o3j8Xb5x8Z7E409CKazMTiHCJPuolMRs4pJzxvmUw2QwyObIzju3GehlsjcIGllLg2x \
AR0NK5khnkw_ydM3BOLgOFUbLZBXzlRDcVb9T__h0YSgiJ_2Fpgd44uM23NFnq3H1u7fv_2e6Sc-lfi33X46cX \
TGzvvHxtWdgH4iABF8zmLptsGdpXhv2hL1osjSF2978fS_-tstawzU6t1pujr-2RDRvEbku175KMhpwzM7m7oN \
c2GlGLWb6sNb79V7OkkmWDv8O5WrHqw9PEIN0xd8RPURqo4qBmuDfUL3y1bv9YHGaL9Pnbn_xQqnfmZxZDvbQp \
zRG_sbUT_h1uCM3C-UHTKx9v_zN0QpfYS5MiyWQ_tN2e39_N-sPcr1Z7tr73WZFuzu1Wa_299u9rPVar2lVb7Y \
zKxuy8VBtf6u2P2bmUC_rerldL1fr5aZeLnR71-Jos2vWjd6pptosaZDGLjjwwoduFg4FQ5O7iEVmMX4uyhhN54gu98uceh8OrrMgKP01K3gPBezfu2bW2A">



[Attachment #3 (text/plain)]

_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[prev in list] [next in list] [prev in thread] [next in thread]