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

    <tr>
        <th>Summary</th>
        <td>
            `-M` output broken by automatic `<angled>` to `"quotes"` remapping
        </td>
    </tr>

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

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

    <tr>
      <th>Reporter</th>
      <td>
          boris-kolpackov
      </td>
    </tr>
</table>

<pre>
    Consider this setup:

```
$ touch hello.h
$ echo '#include <hello.h>' >hello.c

$ clang -MD -MF - "$(pwd)/hello.c"
/tmp/hello.c:2:10: error: 'hello.h' file not found with <angled> include; use "quotes" instead
    2 | #include <hello.h>
 |          ^~~~~~~~~
      |          "hello.h"
hello.o: /tmp/hello.c /tmp/hello.h
1 error generated.

$ echo $?
1
```

What happens here is `<hello.h>` is not found so Clang tries to speculatively remap it to `"hello.h"` if one exists, for diagnostics. But then it also continues processing this `"hello.h"` as if that's what was actually included by the user and it in turn ends up in the `-MD` output (notice the last entry, which is `/tmp/hello.h`).

I think it's wrong for Clang to present such speculations as facts in the dependency information. Now one may argue that it's ok since the compiler still exits with a non-zero status. The problem here is that if the dependency information is written to `stdout`, it may get acted upon before the exist code is known. At least this is what happens in `build2`: we enter the dependency information as it becomes available assuming it is not bogus. When we later see the error exist status it's not easy for us to undo all of that nor is it possible to understand which entries are actually bogus.

Looking at the code, one possible fix would be not to return such a speculatively remapped header from `LookupHeaderIncludeOrImport()` if one of the `-M` options are in effect.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJx8VUFv4zoO_jXKhUiQyEmTHHLotA12gJ3dywJzliU61kYW_SSqmbzD--0PtJ1kWsw8o3BjiSI_fvxImZz9KSIe1OaL2rzOTOGW0qGm5PP8TKE39kzvs5rc9fBCMXuHCbj1GTJy6VX1rJavanl7Py2nv_FTr4Gp2BZaDIEW7WMZbUug9FbpykcbikNQ1cvNrHpTeguqehsX7IcYeg02mHiC-bdXmH87whyU1kqvld71F6f0Xunj7aDWt1NH7vqfNqpnrarn1VJVz4ApUZIfSm9vEPQWGh8QIjE0VKKDi-dWQJp4CuhU9QYTclV9gZJRUPxRiDErrcHHzGjcGB0AQIPavsBv8x3txOT-qM3bX9PzcAOfbLS-I55SHb9pzOdj1p8XpoKsRgbghBGTYXSLz4RP5Vqr6jgd-XXBh_f31jC0pu8xZmgxIfgMYvMh4aelLD_ozQQvQ1k5eczABLlHW4Jh_47hCgk704Nn2RFnHxIXZw1QRMAfPnNW-gUaSuC8OUXK7G1ewJfCwC1GcWJCJrAU2ceCGfpEFnP2Er6d0H4OYLLE4Naw0tsMF8nyYjIYy8WEcL3JwUF9lTiiiQQmOonnI3BJETC6DKUfvluUOPNvr-KdCveFQeldJPYWh-1gMgNGTldJ6NJ62964_FxIWdp_qNtXSSWewU94E8XTQMpEM0GfMGNkyNKid7YpZsm1MZbzDafDHqPDaCXLhlI32C3gP3QZWO_MFUw6FRz4uYWkM2Qfp1wsdb0PmCCzD0HqxHnsKQOR4vxPTASZDZe8gP-1KDWpA3Z3BY2em3_AI1aX5JkxTirJ7KjwQM6LlEFwnpClZuig9BShxobSCHHQDlhyQ7xzpEtcwDNDQKnDIAw_Ff4mbx8lTF18cHqQ-DNcUEo2jMnfAhUtMdRoqcMM5t34YOqAYHIunahQJDN2R00nYeS7CPcikhDXGSfEQ9-OuEfubtzLUTT5OlS8DP1UoiMwIQCNMoZISaJ4hp5y9gJgNMOUWYQ7Kk4EKC1pEj7EPsL6WW__JjoLdMNTvR0K6yKPu_vG_4ALleCgHkcrEyQcOmMQoflV0_fooEUjN0-TqBPCJVbp_zUsfh3b7r_pa9dTYqV3cgU8JgI1j1YbOq2fNC6yioBNg5YXM3eo3L7amxkeVtvlerd70is9aw-7jd4_7audc43brLGpKrPZ2aXb1VajaezMH_RSr5er1XK1qpYrvTCbvdmu9cYZXFW6sWq9xM74sAjhvVtQOs18zgUP2-1mt58FU2PIw_2rdcQLDJsyczavs3SQM_O6nLJaL4OMtocX9hzw8MhrnCB1ojNGmUGmMIne7DR87xeXWN-n6P3KktWRbx9Ps5LCoWXus1zx-qj08eS5LfXCUqf0UUBM_-Z9ov-jZaWPA_Ss9HFI7e8AAAD__05ntR4">