clang-cl, _HAS_EXCEPTIONS, and Microsoft

Here is the latest response from Microsoft to my bug report regarding _HAS_EXCEPTIONS being set to 0 when compiling with VC++ (Microsoft Connect is Retired - Collaborate | Microsoft Docs):

Thank you for reporting.
Macro _HAS_EXCEPTIONS=0 is undocumented and unsupported by Microsoft.
It may work with some parts of the STL library for legacy reasons, but it won't be compatible with ConcRT library (concrt.h) since ConcRT depends on exceptions for cancellation."

The same bug also occurs when compiling with clang-cl. In other words the clang-cl need to have exception handling and give up on the idea that clang-cl can be implemented successfully with _HAS_EXCEPTIONS being set to 0. BTW the concrt.h is being included in Microsoft headers automatically no matter whether _HAS_EXCEPTIONS is set to 0 or not, but I think this is a non-issue from Microsoft's statement above that _HAS_EXCEPTIONS is undocumented and unsupported.

I agree, _HAS_EXCEPTIONS=0 is undocumented and unsupported, but it’s useful to us for the moment. Things are probably going to progress in the following way:

  1. Finish getting clang to self-host with clang-cl with and without optimizations with _HAS_EXCEPTIONS=0. This is blocked by pass-by-value of non-trivial types.
  2. Parse exceptions, but drop them on the floor with a warning like you get from cl /EHs-c-. This should make that confusing error about RTTI mangling go away and have the effect of turning off exceptions.
  3. Make RTTI work, because we need it for exceptions, and it’s fairly simple.
    4 .Make exceptions work.

Programs that rely on exceptions (any user of concrt.h) won’t work until we get to 4, obviously, but I expect there’s a large amount of code that only uses exceptions in STL headers that would work with 2.

My point is that concrt.h is being included by standard Microsoft header files irregardless of whether _HAS_EXCEPTIONS is 0 or not. As soon as concrt.h is included when _HAS_EXCEPTIONS is 0 there will be a compiler error, both in VC++ and clang-cl. So some innocent #include of a standard C++ header file will bring in concrt.h and the error will occur when _HAS_EXCEPTIONS is 0.

If 2) fixes that problem that is fine, but having to set _HAS_EXCEPTIONS to 0 is the cause of the problem and it will not go away until the setting of _HAS_EXCEPTIONS to 0 for clang-cl goes away.