On Thu, 13 Mar 2025 at 21:33, Peter Eisentraut <pe...@eisentraut.org> wrote: > Ok, this is weird, because we have pg_unreachable() support for MSVC: > > #if defined(HAVE__BUILTIN_UNREACHABLE) && !defined(USE_ASSERT_CHECKING) > #define pg_unreachable() __builtin_unreachable() > #elif defined(_MSC_VER) && !defined(USE_ASSERT_CHECKING) > #define pg_unreachable() __assume(0) > #else > #define pg_unreachable() abort() > #endif > > Is there a way to reshuffle those conditionals to make this actually do > something useful on MSVC?
I've just been experimenting with this and it seems the problem isn't with pg_unreachable(), it's with the compiler not understanding that the particular pg_unreachable() is always reached. What's happening is down to the multi-eval protection code for elevel in ereport_domain(). Because elevel is assigned to the variable "elevel_" the compiler seems to lose its proof that the pg_unreachable() is always reached. Adjusting that condition to use the elevel parameter directly makes the warning disappear. I looked around to see if MSVC might have something to allow us to fix this, but didn't find anything. There does not seem to be any sort of __builtin_constant_p with MSVC, otherwise we could've done something similar to the HAVE__BUILTIN_CONSTANT_P version of ereport_domain just above. > Are you compiling with assertions on in this case? Does anything change > about this if you don't use assertions (or vice versa)? It happens with both. David
