[all-commits] [llvm/llvm-project] db3d02: Effectively revert 33c3d8a916c / D33782

[Reid Kleckner via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: db3d029fbe09925ea42a3279b1abb244fa547cff
      https://github.com/llvm/llvm-project/commit/db3d029fbe09925ea42a3279b1abb244fa547cff
  Author: Reid Kleckner <rnk at google.com>
  Date:   2021-08-25 (Wed, 25 Aug 2021)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/lib/Lex/Preprocessor.cpp
    R clang/test/Headers/ms-cppoperkey.cpp
    R clang/test/Headers/ms-cppoperkey1.cpp
    R clang/test/Headers/ms-cppoperkey2.cpp

  Log Message:
  -----------
  Effectively revert 33c3d8a916c / D33782

This change would treat the token `or` in system headers as an
identifier, and elsewhere as an operator. As reported in
llvm.org/pr42427, many users classify their third party library headers
as "system" headers to suppress warnings. There's no clean way to
separate Windows SDK headers from user headers.

Clang is still able to parse old Windows SDK headers if C++ operator
names are disabled. Traditionally this was controlled by
`-fno-operator-names`, but is now also enabled with `/permissive` since
D103773. This change will prevent `clang-cl` from parsing <query.h> from
the Windows SDK out of the box, but there are multiple ways to work
around that:
- Pass `/clang:-fno-operator-names`
- Pass `/permissive`
- Pass `-DQUERY_H_RESTRICTION_PERMISSIVE`

In all of these modes, the operator names will consistently be available
or not available, instead of depending on whether the code is in a
system header.

I added a release note for this, since it may break straightforward
users of the Windows SDK.

Fixes PR42427

Differential Revision: https://reviews.llvm.org/D108720