Refine the conditions for the MSVC constinit workaround

As I understand it, the underlying limitation comes from Windows lacking a runtime relocation that can express pointers to symbols in a different dll. In particular, it seems the generated TcParseTable objects reference libprotobuf symbols under _pbi::TcParser. When libprotobuf is built as a dll, this breaks. See #10159.

There is already a workaround that suppresses all of PROTOBUF_CONSTINIT on MSVC. This is, as far as I can tell, both too broad and too narrow. It is too narrow by excluding clang, when the limitation is Windows-wide, not specific to MSVC. It is too broad by including non-PROTOBUF_USE_DLLS builds, when statically-linked libprotobuf is, as I understand it, fine.

This CL changes the condition to check for PROTOBUF_USE_DLLS && _WIN32, to reflect this being a Windows limitation, not a compiler limitation. As a result:

1. clang-cl + PROTOBUF_USE_DLLS now suppresses constinit. This is the configuration that is broken and should now build. This should be low risk. Turning off constinit should only make the compiler accept more things.

2. MSVC + non-PROTOBUF_USE_DLLS + C++20 restores constinit. If the above is correct, non-PROTOBUF_USE_DLLS never needed the workaround. This avoids regressing constinit on staticly-linked Windows. There is some risk here if I'm wrong and we needed the suppression more broadly.

_WIN32 would also cover MinGW and Cygwin, which were written differently. The MinGW suppression was added in #13240 and cited shared libraries, so it seems this is really the same error and now covered by the fixed condition.

The Cygwin suppression was aded in  #9562 back in 2022, and it is unclear whether that was being built as a shared library. (The error about std::mutex is also odd but it seems to be an issue with constexpr and not constinit? That may be interesting for 7f431bb, but doesn't seem to be related to constinit specifically.) Regardless, there is now a GCC-wide suppression of constinit, so it is *at least* redundant with it, so I've removed it for now. Though if the GCC suppression is removed, we may later learn that Cygwin had a non-dll issue.

Finally, after 7f431bb, some of the PROTOBUF_CONSTINIT logic was a little odd. The version checks, for instance, are now all no-ops because the fallback case is the same. I've cleaned up that code a bit, but those aren't expected to change behavior.

(It's still arguably a workaround because constinit itself is supported by Windows. protobuf just doesn't generate constinit code in this configuration. A real fix might be to rework TcParseTable to avoid function pointers into libprotobuf? Possibly there are other issues to fix too? Not sure. Or perhaps to just declare this build configuration is only half-supported and has to suffer a static initializer.)

PiperOrigin-RevId: 855254095

Author: protobuf-github-bot

src/google/protobuf/port_def.inc

@@ -416,35 +416,30 @@ static_assert(PROTOBUF_ABSL_MIN(20230125, 3),
 #error PROTOBUF_CONSTINIT was previously defined
 #endif
 
-// Lexan sets both MSV_VER and clang, so handle it with the clang path.
-#if defined(_MSC_VER) && !defined(__clang__)
-// MSVC 17 currently seems to raise an error about constant-initialized pointers.
-# if PROTOBUF_MSC_VER_MIN(1930)
+#if defined(PROTOBUF_USE_DLLS) && (defined(_WIN32) || defined(__CYGWIN__))
+// On Windows, `constinit` structures cannot include pointers to dllimport
+// symbols, which are defined in another dll. If libprotobuf is built as a dll,
+// generated parse tables breaks this. See
+// https://github.com/protocolbuffers/protobuf/issues/10159 and
+// https://github.com/protocolbuffers/protobuf/pull/13240. Work around this by
+// suppressing `constinit`.
 #define PROTOBUF_CONSTINIT
-# endif
 #elif defined(__GNUC__) && !defined(__clang__)
 // GCC doesn't support constinit aggregate initialization of absl::Cord.
-# if PROTOBUF_GNUC_MIN(12, 2)
 #define PROTOBUF_CONSTINIT
-# endif
-#else
-# if defined(__cpp_constinit) && !defined(__CYGWIN__)
+#elif defined(__cpp_constinit)
 #define PROTOBUF_CONSTINIT constinit
-#  define PROTOBUF_CONSTINIT_DEFAULT_INSTANCES
+#define PROTOBUF_CONSTINIT_DEFAULT_INSTANCES
 // Some older Clang versions incorrectly raise an error about
 // constant-initializing weak default instance pointers. Versions 12.0 and
 // higher seem to work, except that XCode 12.5.1 shows the error even though it
 // uses Clang 12.0.5.
-#elif !defined(__CYGWIN__) && !defined(__MINGW32__) &&                 \
-    ABSL_HAVE_CPP_ATTRIBUTE(clang::require_constant_initialization) && \
-    ((defined(__APPLE__) && PROTOBUF_CLANG_MIN(13, 0)) ||              \
+#elif ABSL_HAVE_CPP_ATTRIBUTE(clang::require_constant_initialization) && \
+    ((defined(__APPLE__) && PROTOBUF_CLANG_MIN(13, 0)) ||                \
      (!defined(__APPLE__) && PROTOBUF_CLANG_MIN(12, 0)))
 #define PROTOBUF_CONSTINIT [[clang::require_constant_initialization]]
-#  define PROTOBUF_CONSTINIT_DEFAULT_INSTANCES
-# endif
-#endif
-
-#ifndef PROTOBUF_CONSTINIT
+#define PROTOBUF_CONSTINIT_DEFAULT_INSTANCES
+#else
 #define PROTOBUF_CONSTINIT
 #endif