PR #12644 enables asserts for MSVC RelWithDevInfo by adjusting CMAKE_CXX_FLAGS_RELWITHDEBINFO:

string(REPLACE "/DNDEBUG" " " CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")

Implementation differs from setting CMAKE_CXX_FLAGS for GNU/Clang though:

set(CMAKE_CXX_FLAGS_DEBUG          "-O0 -g3 -DETH_DEBUG")
set(CMAKE_CXX_FLAGS_MINSIZEREL     "-Os -DNDEBUG")
set(CMAKE_CXX_FLAGS_RELEASE        "-O3 -DNDEBUG")
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -g3")

It fails locally, as expected, but succeeds on CI, which runs Release.

I do support the idea to enable the standard C++ asserts. I would even consider doing it in Release, even if that sounds unorthodox.

Please check the performance. For boost multiprecision, it makes a huge difference if it is built in debug or release mode. I would not be surprised if they also use some assertions.

Does not seem to affect runtime performance in a significant way:

The non-release jobs ran slightly slower but still within the normal variability we see in CI so it might not even be actual slowdown. Even if it is, it seems to be small enough to be acceptable.

It fails locally, as expected, but succeeds on CI, which runs Release.

I think it runs RelWithDebInfo actually (as long as we're talking about Linux runs). For example for b_ubu we do not specify build type in .circleci/config.yml so it should be RelWithDebInfo. So I guess assertions should be enabled there? Have you checked this one specifically?

It looks like we should add CMAKE_BUILD_TYPE=Release to some release jobs though, like b_ubu_release. Right now it does not specify anything so it must be running RelWithDebInfo too. Unless we're doing that on purpose?

We should check some more computation-intensive examples. Most of our tests do not need a lot of computation on bigints, but for example the linear solver will.