Windows: Tests failing due to SIGinvalid

[divark]

Hello! Thank you for making this library. I've been using it extensively in my TSLCompiler project.

I found an issue when running tests, where occasionally, some or all of my tests would fail with a SigInvalid, specifically on Windows. Here's an example from a CI run:

5/5 errors     FAIL            0.03s   (exit status 3221225477 or signal 3221225349 SIGinvalid)
------------------------------------- 8< -------------------------------------

Feature: An error message should be provided when an issue comes up with the Lexer or Parser.
Scenario: The Parser reports an invalid Category.
Given a TSL input file called invalid_category.txt,
When the error messages are redirected to be read by us,
When the Parser consumes the input,
Then line 1 of the error message should mention finding 'Property variable' in the wrong spot.
Then line 2 of the error message should mention the given TSL input file at line 1, column 3.
Then line 3 of the error message should point to the token Huh? in line 1 with line 2 below it.
Scenario: The Parser reports an invalid Choice.
Given a TSL input file called invalid_choice.txt,
When the error messages are redirected to be read by us,
When the Parser consumes the input,
Then line 1 of the error message should mention finding 'Property variable' in the wrong spot.
Then line 2 of the error message should mention the given TSL input file at line 2, column 7.
Then line 3 of the error message should point to the token Huh? in line 2 with line 3 below it.
Scenario: The Parser reports an error for the common case of a property followed by an if statement.
Given a TSL input file called invalid_property_then_if.txt,
When the error messages are redirected to be read by us,
When the Parser consumes the input,
Then line 1 of the error message should mention finding 'Constraint' in the wrong spot.
Then line 2 of the error message should mention the given TSL input file at line 5, column 43.
Then line 3 of the error message should point to the token if in line 5 with line 6 below it.
Error: o: The Parser reports an error for the common case of a [single][error].
Given a TSL input file called invalid_double_marking.txt,
When the error messages are redirected to be read by us,
When the Parser consumes the input,
Then line 1 of the error message should mention finding 'Error marking' in the wrong spot.
Then line 2 of the error message should mention the given TSL input file at line 3, column 39.
Error: Then line 3 of the error message should point to the token [error] in line 3 with line 4 below it.
Scenario: The Parser reports an undefined property error when a property used was defined in the same Category.
Given a TSL input file called defined_property_used_in_same_category.txt,
When the error messages are redirected to be read by us,
When the Parser consumes the input,
Then line 1 of the error message should mention 'Property test1 not defined in any prior Categories.'.
Then line 2 of the error message should mention the given TSL input file at line 3, column 33.
Then line 3 of the error message should point to the token test1 in line 3 with line 4 below it.
Scenario: The Parser reports an undefined property error if the property was never defined.
Given a TSL input file called undefined_property.txt,
When the error messages are redirected to be read by us,
When the Parser consumes the input,
Then line 1 of the error message should mention 'Property test2 not defined in any prior Categories.'.
Then line 2 of the error message should mention the given TSL input file at line 3, column 33.
Then line 3 of the error message should point to the token test2 in line 3 with line 4 below it.
Scenario: The Parser reports a duplicated property error if the property was defined twice.
Given a TSL input file called duplicate_property.txt,
When the error messages are redirected to be read by us,
When the Parser consumes the input,
Then line 1 of the error message should mention 'Property test2 was already defined elsewhere.'.
Then line 2 of the error message should mention the given TSL input file at line 3, column 39.
Then line 3 of the error message should point to the token test2 in line 3 with line 4 below it.Suite 'global': all tests passed (28 asserts in 1 tests)
------------------------------------------------------------------------------

I turned on address sanitization, and every test that failed reports an access violation. Here's a sample from another CI run with address sanitization turned on:

stderr:
=================================================================
==7376==ERROR: AddressSanitizer: access-violation on unknown address 0xffffffffffffffff (pc 0x7ff91afb3990 bp 0x005c41fcea10 sp 0x005c41fce988 T0)
==7376==The signal is caused by a READ memory access.
    #0 0x7ff91afb398f  (C:\Windows\SYSTEM32\ntdll.dll+0x18009398f)
    #1 0x7ff8e725d376 in strlen (D:\a\_temp\msys64\clang64\bin\libclang_rt.asan_dynamic-x86_64.dll+0x18003d376)
    #2 0x7ff8fca460c3 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__assign_external(char const*) (D:\a\_temp\msys64\clang64\bin\libc++.dll+0x1800460c3)
    #3 0x7ff674d27f9e in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::operator=[abi:fe190107](char const*) D:/a/_temp/msys64/clang64/include/c++/v1/string:1243:12
    #4 0x7ff674d46377 in boost::ext::ut::v2_3_0::detail::cfg::parse(int, char const**) D:/a/TSLCompiler/TSLCompiler/build/../subprojects/ut/include/boost/ut.hpp:790:23
    #5 0x7ff674d45f93 in boost::ext::ut::v2_3_0::detail::cfg::parse_arg_with_fallback(int, char const**) D:/a/TSLCompiler/TSLCompiler/build/../subprojects/ut/include/boost/ut.hpp:784:5
    #6 0x7ff674d4562d in boost::ext::ut::v2_3_0::reporter_junit<boost::ext::ut::v2_3_0::printer>::on(boost::ext::ut::v2_3_0::events::run_begin) D:/a/TSLCompiler/TSLCompiler/build/../subprojects/ut/include/boost/ut.hpp:1684:5
    #7 0x7ff674d450dc in boost::ext::ut::v2_3_0::runner<boost::ext::ut::v2_3_0::reporter_junit<boost::ext::ut::v2_3_0::printer>, 16>::run(boost::ext::ut::v2_3_0::run_cfg) D:/a/TSLCompiler/TSLCompiler/build/../subprojects/ut/include/boost/ut.hpp:2195:15
    #8 0x7ff674cfc251 in boost::ext::ut::v2_3_0::runner<boost::ext::ut::v2_3_0::reporter_junit<boost::ext::ut::v2_3_0::printer>, 16>::~runner() D:/a/TSLCompiler/TSLCompiler/build/../subprojects/ut/include/boost/ut.hpp:2027:25
    #9 0x7ff674ce71f5 in __dtor__ZN5boost3ext2ut6v2_3_03cfgINS2_8overrideEJEEE D:/a/TSLCompiler/TSLCompiler/build/../subprojects/ut/include/boost/ut.hpp
    #10 0x7ff9186ebdbf  (C:\Windows\System32\ucrtbase.dll+0x18001bdbf)
    #11 0x7ff9186ebcd6  (C:\Windows\System32\ucrtbase.dll+0x18001bcd6)
    #12 0x7ff9186ebc8c  (C:\Windows\System32\ucrtbase.dll+0x18001bc8c)
    #13 0x7ff9186ea079  (C:\Windows\System32\ucrtbase.dll+0x18001a079)
    #14 0x7ff9186ea00e  (C:\Windows\System32\ucrtbase.dll+0x18001a00e)
    #15 0x7ff9186e9fae  (C:\Windows\System32\ucrtbase.dll+0x180019fae)
    #16 0x7ff674c8137d in __tmainCRTStartup C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:268:7
    #17 0x7ff674c81395 in .l_start C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:186:9
    #18 0x7ff919f14caf  (C:\Windows\System32\KERNEL32.DLL+0x180014caf)
    #19 0x7ff91af9edca  (C:\Windows\SYSTEM32\ntdll.dll+0x18007edca)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: access-violation (C:\Windows\SYSTEM32\ntdll.dll+0x18009398f) 
==7376==ABORTING

It seems the problem comes from this snippet in ut.hpp, where argv[0] is a nullptr on Windows:

  static void parse(int argc, const char* argv[]) {
    const std::size_t n_args = argc > 0 ? static_cast<std::size_t>(argc) : 0U;
    if (n_args > 0 && argv != nullptr) {
      executable_name = argv[0];
    }
    ...

And I was able to fix it by moving the call to parse here:

static void parse_arg_with_fallback(int argc, const char* argv[]) {
    if (argc > 0 && argv != nullptr) {
      cfg::largc = argc;
      cfg::largv = argv;
      // Now it's here.
      parse(cfg::largc, cfg::largv);
    }
    // WAS ORIGINALLY HERE: parse(cfg::largc, cfg::largv);
  }

I'm not sure whether this was an appropriate fix, but it seems to be passing all of the CI tests in my fork. Any idea on what's going on?