Test structure is stressful in terms of compiler memory consumption

Comienza con test/merge_separate.cpp en las líneas 21-47, donde se muestra la larga lista de static_asserts e instanciaciones. Revisa las pruebas relacionadas con la misma estructura y, después, usa MSVC con /d1reportMemorySummary para comparar el tamaño máximo del working set del compilador. Se considera terminado cuando la estructura de la prueba afectada se haya refactorizado en funciones separadas y siga pasando.

Hi Boost.Parser devs! I'm the primary maintainer of MSVC's STL, and our compiler team has encountered issues with recent MSVC STL changes (specifically our implementation of C++23 reference_meows_from_temporary in tuple's constructors) causing Boost.Parser tests to have excessive compiler memory consumption, reaching out-of-memory for our accursed 32-bit x86-hosted compiler. (We regularly test open-source projects, especially Boost, with development builds of the compiler and libraries to find and fix regressions before they can ship and affect you.)

This is not a bug in your tests so you can close this issue if you like. However, I wanted to at least mention that the specific structure of the tests is leading to this excessive compiler memory consumption and a simple refactoring would make them less likely to OOM, and (as a benefit to you) probably a bit faster to compile.

The issue is when main() or any function has a long list of static_asserts and instantiations like this:

https://github.com/boostorg/parser/blob/293f5e1e3f491f9219e69269f464da6f2ab9ff94/test/merge_separate.cpp#L21-L47

Even though this code is in separate scopes, they're still within the same function, so the compiler doesn't reuse memory effectively. If these were in separate functions, then I believe the compiler memory consumption would be limited. (I don't have an exhaustive list of tests affected, this is just the one in the error message I saw.)

If you're interested in doing this, the undocumented but very useful compiler option /d1reportMemorySummary will report memory consumption. Here's an example showing how <print> is a chonker compared to <cstdio>, "Peak working set size" is the value of interest:

C:\Temp>type meow.cpp
#ifdef USE_CXX23
#include <print>
#else
#include <cstdio>
#endif

int main() {
#ifdef USE_CXX23
    std::println("Hello C++23 world!");
#else
    std::puts("Hello C++98 world!");
#endif
}

C:\Temp>cl /EHsc /nologo /W4 /MTd /Od /std:c++14 /d1reportMemorySummary meow.cpp && meow
meow.cpp
Persistent heap 1 size: 5424544
Persistent heap 2 size: 1255624
Peak working set size: 20422656
Hello C++98 world!

C:\Temp>cl /EHsc /nologo /W4 /MTd /Od /std:c++latest /DUSE_CXX23 /d1reportMemorySummary meow.cpp && meow
meow.cpp
Persistent heap 1 size: 84938280
Persistent heap 2 size: 4237816
Peak working set size: 113741824
Hello C++23 world!