[NFC] Move __CORRECT_ISO_CPP_WCHAR_H_PROTO closer to wchar.h include

[rupprecht]

Summary

This is only necessary for wchar.h, so only set it if we're including that.

[rupprecht]

• Fix some indentation

[iana]

Either way is fine with me. I didn't think about wchar.h, maybe better to leave that one the way it is to be on the safe side, and leave __mbstate_t.h the way you have it already for consistency.

[sylvestre.ledru]

fyi, it doesn't fix
https://github.com/llvm/llvm-project/issues/62523

[rupprecht]

I forgot about this patch but I won't be around to watch it go through buildbots etc., so I'll plan to land it as soon as I get back in a couple weeks.

In D150322#4333650, @iana wrote:

Either way is fine with me. I didn't think about wchar.h, maybe better to leave that one the way it is to be on the safe side, and leave __mbstate_t.h the way you have it already for consistency.

I guess I also don't have a preference either way, but I think consistency is important -- trying to reason whether __CORRECT_ISO_CPP_WCHAR_H_PROTO affects one place but not the other is just real estate I don't want my brain to spend time on.

In D150322#4352194, @sylvestre.ledru wrote:

fyi, it doesn't fix
https://github.com/llvm/llvm-project/issues/62523

I wouldn't expect it to. At least in the sources I'm looking at, __CORRECT_ISO_CPP_WCHAR_H_PROTO should only affect the function signatures of wcschr, wcsrchr, wcspbrk, and wcsstr.

[Mordante]

In D150322#4354896, @rupprecht wrote:

I forgot about this patch but I won't be around to watch it go through buildbots etc., so I'll plan to land it as soon as I get back in a couple weeks.

Does this main the breakage of D150015 will remain for a couple of weeks. If so I think we should revert D150015 and look at a good solution for you when you're back. WDYT?

[rupprecht]

In D150322#4356560, @Mordante wrote:

In D150322#4354896, @rupprecht wrote:

I forgot about this patch but I won't be around to watch it go through buildbots etc., so I'll plan to land it as soon as I get back in a couple weeks.

Does this main the breakage of D150015 will remain for a couple of weeks. If so I think we should revert D150015 and look at a good solution for you when you're back. WDYT?

No, this change itself should be NFC. D150015 is a fix for D148542. So please don't revert D150015, unless it's part of also reverting D148542 if you choose to do that for https://github.com/llvm/llvm-project/issues/62523.

D148542 looks like a bug fix for something else, so I don't know if it's a good idea to revert. Check with @iana I guess?

libcxx/include/__mbstate_t.h

 // or <wchar.h>, hence the #include_next of those headers instead of #include.
 // (e.g. if <wchar.h> isn't present in the C library, the libc++ <wchar.h>
 // will include this header. This header needs to not turn around and cyclically
 // include <wchar.h>, but fall through to <uchar.h>.)
 //
 // This does not define std::mbstate_t -- this only brings in the declaration
 // in the global namespace.
 
+#if __has_include(<bits/types/mbstate_t.h>)
+#  include <bits/types/mbstate_t.h> // works on most Unixes
+#elif __has_include(<sys/_types/_mbstate_t.h>)
+#  include <sys/_types/_mbstate_t.h> // works on Darwin
+#elif !defined(_LIBCPP_HAS_NO_WIDE_CHARACTERS) && __has_include_next(<wchar.h>)
+// Some older versions of <wchar.h> do not define this for clang, so we do it ourselves.
 // We define this here to support older versions of glibc <wchar.h> that do
 // not define this for clang. This is also set in libc++'s <wchar.h> header,
 // and we need to do so here too to avoid a different function signature given
 // a different include order.
-#ifdef __cplusplus
-#  define __CORRECT_ISO_CPP_WCHAR_H_PROTO
-#endif
-
-#if __has_include(<bits/types/mbstate_t.h>)
-#   include <bits/types/mbstate_t.h> // works on most Unixes
-#elif __has_include(<sys/_types/_mbstate_t.h>)
-#   include <sys/_types/_mbstate_t.h> // works on Darwin
-#elif !defined(_LIBCPP_HAS_NO_WIDE_CHARACTERS) && __has_include_next(<wchar.h>)
-#   include_next <wchar.h> // fall back to the C standard provider of mbstate_t
+#  ifdef __cplusplus
+#    define __CORRECT_ISO_CPP_WCHAR_H_PROTO
+#  endif
+#  include_next <wchar.h> // fall back to the C standard provider of mbstate_t
 #elif __has_include_next(<uchar.h>)
-#   include_next <uchar.h> // <uchar.h> is also required to make mbstate_t visible
+#  include_next <uchar.h> // <uchar.h> is also required to make mbstate_t visible
 #else
-#   error "We don't know how to get the definition of mbstate_t without <wchar.h> on your platform."
+#  error "We don't know how to get the definition of mbstate_t without <wchar.h> on your platform."
 #endif
 
 #endif // _LIBCPP___MBSTATE_T_H

libcxx/include/wchar.h

 #if defined(_LIBCPP_HAS_NO_WIDE_CHARACTERS)
 #   error "The <wchar.h> header is not supported since libc++ has been configured with LIBCXX_ENABLE_WIDE_CHARACTERS disabled"
 #endif
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
+#  if __has_include_next(<wchar.h>)
 // We define this here to support older versions of glibc <wchar.h> that do
 // not define this for clang.
-#ifdef __cplusplus
-#define __CORRECT_ISO_CPP_WCHAR_H_PROTO
-#endif
-
-#  if __has_include_next(<wchar.h>)
+#    ifdef __cplusplus
+#      define __CORRECT_ISO_CPP_WCHAR_H_PROTO
+#    endif
 #    include_next <wchar.h>
 #  else
 #    include <__mbstate_t.h> // make sure we have mbstate_t regardless of the existence of <wchar.h>
 #  endif
 
 // Determine whether we have const-correct overloads for wcschr and friends.
 #if defined(_WCHAR_H_CPLUSPLUS_98_CONFORMANCE_)
 #  define _LIBCPP_WCHAR_H_HAS_CONST_OVERLOADS 1