[cfe-dev] Adding /permissive to clang-cl

[Markus Böck via cfe-dev]

Hello everyone!

I would like to add /permissive and /permissive- from MSVC to
clang-cl. MSVC has historically had issues with compliance with the
C++ Standard which has later led to them adding the flag /permissive,
to allow users non C++ conforming code to still compile, while others
can use the /permissive- flag to have stricter C++ conformance.

For reasons I am going to discuss in a bit I would like to also add
the /permissive and /permissive- flag. /permissive- is basically like
clang-cl acts at the moment and I'd like to keep it as default.
/permissive however would do the equivalent of:
* /Zc:twoPhase-
* /Zc:strictStrings-
and turning off C++ operator keywords, treating them as identifiers
instead (or, and, xor, compl etc).
If future Microsoft specific extensions are added they should also be
affected by /permissive.

Motivation:
Due to a need to be able to parse the Windows headers a patch was
added in 2017 (https://reviews.llvm.org/D33782), which treats the
operator keywords as identifiers when inside a system header. This
raises a few issues however, most recently in libc++ which had
concepts code using `and`, which then failed to compile due to being a
system header (via #pragma GCC system_header). This has also caused
various issues for library vendors as can be seen here
https://bugs.llvm.org/show_bug.cgi?id=42427 and here
https://github.com/nlohmann/json/issues/1818. Additionally, in the use
case of the patch above, where the struct had a field called `or`, it
makes the field inaccessible from clang-cl, as user code still uses
the `or` keyword, while the header lexes it as an identifier.

I would like to effectively revert the above mentioned patch and
instead add /permissive and /permissive- as compile flags to clang-cl.
Microsoft has put work into making the Windows SDK headers C++
conforming and has documented the specific headers that they still
have issues with. For those they also officially recommend simply
using /permissive for those specific source files including them:
https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-160#windows-header-issues.

My only concern with this patch is that this is a breaking change.
Scenario: A user has a project using the query.h header from the
Windows SDK has been using clang-cl exclusively to compile their
project. A source file including that header makes use of the C++
operator keywords. After this proposed change it would first fail to
compile, they'd then as Microsoft recommends use the /permissive flag
but then still fail to compile as they make use of C++ operator
keywords, which were turned off.

Are there any ideas about how to mitigate this issue? Does anyone know
how common such a scenario is?
MSVC apparently makes use of the ciso646 header to add the C++
operator keywords as macros to their respective operator which could
be used as mitigation for the above (once again matching MSVC
behaviour) but that currently does not seem to work with clang-cl.

Greetings
Markus Böck