[all-commits] [llvm/llvm-project] 0ec57b: [libc++] Consistently enable __CORRECT_ISO_CPP_WCH...

[Jordan Rupprecht via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0ec57bf7b18e8918dd8ced007a88467b798677c6
      https://github.com/llvm/llvm-project/commit/0ec57bf7b18e8918dd8ced007a88467b798677c6
  Author: Jordan Rupprecht <rupprecht at google.com>
  Date:   2023-05-10 (Wed, 10 May 2023)

  Changed paths:
    M libcxx/include/__mbstate_t.h
    M libcxx/include/wchar.h
    A libcxx/test/std/strings/c.strings/cwchar_include_order1.compile.verify.cpp
    A libcxx/test/std/strings/c.strings/cwchar_include_order2.compile.verify.cpp

  Log Message:
  -----------
  [libc++] Consistently enable __CORRECT_ISO_CPP_WCHAR_H_PROTO in mbstate.

In libc++'s `wchar.h`, before we forward to the system `wchar.h`, we set `__CORRECT_ISO_CPP_WCHAR_H_PROTO` to ensure it defines the correct signature (e.g. `extern "C++" const wchar_t *wmemchr` and not `extern wchar_t *wmemchr`). After D148542, there are cases where we include the system `wchar.h` from within `__mbstate_t.h` without setting that, and so we get a function type mismatch if we transitively include `wchar.h` through multiple headers in a modules-enabled build. Consistently setting it here resolves those build errors.

Alternative 1: we could put this in `__config` instead. I chose to put it here for a more limited scope.

Alternative 2: we could patch `wchar.h` itself to work correctly and remove references `__CORRECT_ISO_CPP_WCHAR_H_PROTO` from libc++ entirely. It does already set it, but with an additional condition that it is being built by GCC >= 4.4. Clang does pretend to be GCC via `__GNUC__` etc. which can be controlled via `-fgnuc-version` command line flags, but that might have other consequences.

Reviewed By: ldionne, #libc, MaskRay

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