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

    <tr>
        <th>Summary</th>
        <td>
            clang-cl incompatibility with MSVC-compliant template parsing
        </td>
    </tr>

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

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

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

<pre>
    Given the following example code, MSVC with `/permissive-` compiles it successfully, but clang-cl (14.0.0 tested) with same flag yields an error:

```cpp
struct CCache &GCache();

template <typename ObjectType>
struct CObjectRef
{
        void Lock()
        {
                GCache().LoadObject();
        }
};

struct CCache
{
        bool LoadObject();
};
```
https://godbolt.org/z/86xf15sK5

This error doesn't occur with clang-cl 12.0.0, but I believe that's because that version of clang-cl would always enable `-fdelayed-template-parsing` regardless of the presence of clang-cl seeing `/permissive-` (as evidenced via seeing the expanded command line using `-v`). I've seen mention of that flag being disabled by default from Windows targets but I wasn't able to find a corresponding commit/issue discussing the actual work done to make that change.

I would assume that clang is correct here in its strictness, and as such I've filed a bug against MSVC, but I'm unable to find something in the standard that defines what is more compliant. https://developercommunity.visualstudio.com/t/Delayed-template-parsing-divergence-from/10011903

But, as far as I can tell there's currently no workaround for this issue with clang-cl, because whenever `/permissive-` is passed to clang-cl, it ignores any `-fdelayed-template-parsing` and doesn't pass it to the "actual" front-end (sorry my terminology is a bit loose here, still learning how these pieces fit together). So an upgrade from clang-cl 12 to clang-cl 14 results in compiler errors that cannot be prevented without reworking the code or dropping `/permissive-` entirely from clang-cl builds.

I don't have a strong proposal here, but it seems reasonable (and plausible) that clang-cl could "combine" an explicit pairing of `/permissive-` and `-fdelayed-template-parsing` to not discard the latter.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyFVttu4zYQ_Rr5hbAhy_cHPzROswi6RYHuon2mxLHMDUUKJGVH_fqe0cWxswkWcBKZIocz5zKT3Kl2_0WfyYp4InF0xriLtqWgV1nVhkThFCXZQfz57Z-DuOh4Esk6TbKnmnylQ8DJKRawraq1oSB0FKEpCgrh2BjT8tG8iaIw0pbTwogk286Xs3SWikghkkqyXR82yAr3G1mKVpNRQUgryHvnk8VvSfqYpONvXN99irruV0L0TRHF4SALlJBk6y_dE25C8GTxcHs6EqqSEdsWh9jWZPnWv_IfVMTv-Josfr-P2b_6m45DkM012u7stBJfXfEyXDSu3-7B5zaZ2VcnVR_yp-xw7nG85PFd1ncV_pxJ7pwRn4e-DTeC1389xVgHxjd7wqd0Kncmzpwv8e0__GzXr8f5Kvyxuk3m-0mHnhmhHAWbZJsoXFE0vifySvU8Y55HBTyLnIymM0FoEjluAhYK2YR-QZzJB-2scMe3CBfXGCWkucgWV1qZQ5BIfnpUZGRLajrSOa0lTtuSpeiplF5Bi4FjsaprT4FsQXexAxHr_EM1A0GJC89a8TElzlqO-zkevdbSKqxD9RWehNGWRBOGeNNzF3Q3E88oEwXjqBUV2TjU19XbST3vYioduDQl8lYoOsrG4LV3lfhXW-UuQUTpS4phwPEiB9A7PKITR2wTEtl4FFo7qzgo56aB8xPqaojvKJoQxhJkERvJAPsXsGi7MJV8GbgoTgCJZresP49kIFo1bmMsBdTQ3QyBnsiT0BZNIAhoVhfRggZWAKMESNEaTiMqR80lSxRVCllKbUPsusxVMNhWicbeVRlcRfHEVei-Y4WI0OC7zwjogYogLvwFiVXOU9ebjJY2zsS94BXUaBy4Z6waq2M7O-sAXEJslHYzLGMXY_j4id6mCpIBN1DJlBnD1nmazue7dHEL3kMTOxCCOErPf55FgfYWyRguwlNnBzjIQySmFdZ1zEjvGtR8hNMim65n8s5kHViDjS4nsqjIf6xpnK9BHiAHlrfH0bF1aQEUt9z21_5iKt-MzzE5BILGrvtmvbTwwBq2cUrYD0MFaKQVVYuqkZd1xpUtJwUB4LhxDhX0UBxAqgYyhqS3TPXJXTg4NtSaMFogBb4QlsCBzmjfHI-Lpi69VNR756YN3VYs5kt0iACLBZbQMLd839DCoGtprYvAlTsHRiPGVIe6gyo9MTOjjXg6Cm6E3tX1p-2Ene8JvN4nljcac-6dy2DGDteThEUku8ghbI34LsCwI0JsEB61RFVATjK4oTuicwFvkIZ2hAUer29e5VuLzsagB6XnMAsTxaP2FR4pNBOqPVeCPvVhMRz-lxoB4IwgN53emySwBczPJmq_ULvFTk6ijob217y0ZS5k1Lk2cGIvc-4H06t_xXV6D1dNGm_274YYjjX5YF1jzuOfKSDsh2PfENGVnlbL7WY9Oe2XWZapTbbcLBeL1Xa52KYqU7mUcjtfpcW8mBiJ2RX2yeoBaFm69E7Ec7J6nOh9lmZZupxn8122Wa1ntFTr9WKzUtnmqNJskyxTqqQ2M86Dp-vE77uU0PkCXhodYnh7CUPBj0TddYgvGyjP75W0-L_oB1m2RJh0Gey7Cv4HMnM9jw">