change mimalloc_rust build to more strictly follow original mimalloc sources build system

[Havunen]

This PR fixes: #159

Its a workaround to compile the mimalloc using C++ compiler for Windows ARM / MSVC family

Original issue has been raised to mimalloc: microsoft/mimalloc#1277

However, there were some differences in this Rust mimalloc build system compared to mimalloc official sources, this PR addresses those.

tested here: Auto-Explore/GitComet#160

GPT 5.4 Analysis

• For the Windows ARM/MSVC-family bug, the highest-priority gap is that git/mimalloc_rust/libmimalloc-sys/build.rs:27 still compiles src/
  static.c and only does build.cpp(true) on MSVC-like compilers at git/mimalloc_rust/libmimalloc-sys/build.rs:85. Upstream is stronger: it
  forces C++ on MSVC/clang-cl and treats src/static.c as C++ source in CMakeLists.txt:177 and CMakeLists.txt:577. I would add c++17, /Zc:__cplusplus, and
  either /TP or a .cc wrapper around static.c.

• For release parity, build.rs only sets MI_DEBUG=0 in non-debug builds at git/mimalloc_rust/libmimalloc-sys/build.rs:75. Upstream also adds
  MI_BUILD_RELEASE in release-like configs at CMakeLists.txt:612. That matters because the vendored source checks MI_BUILD_RELEASE/NDEBUG separately in /
  home/sampo/git/mimalloc_rust/libmimalloc-sys/c_src/mimalloc/v3/include/mimalloc/types.h:73 and git/mimalloc_rust/libmimalloc-sys/c_src/
  mimalloc/v3/src/os.c:140. I would define MI_BUILD_RELEASE and NDEBUG in non-debug Cargo profiles.

• For arm64 performance, the Rust wrapper has no equivalent to upstream MI_OPT_ARCH. Upstream auto-enables that on arm64 in CMakeLists.txt:162 and uses
  -march=armv8.1-a or /arch:armv8.1 in CMakeLists.txt:505. That is the main missing perf flag.

• Optional but useful: expose MI_WIN_DIRECT_TLS=1 as an opt-in Windows feature from CMakeLists.txt:422, and add -fno-builtin-malloc when the Rust override
  feature is used, to match CMakeLists.txt:488

[octavonce]

@Havunen This looks good but maybe we should simply pull the dev3 branch since it contains the fix and we continue using the C compiler? What do you think?

You could pull it in this PR since it also adds a few more useful flags.

[Havunen]

@octavonce Ok, I updated submodules to point dev2 and dev3 HEADs so the fix is included in both.

The previous build script already had this line:

   if build.get_compiler().is_like_msvc() {
        build.cpp(true);
    }

So I thought It already compiled using c++, but for some reason it did not. It now more strictly tries to follow the same build process how mimalloc upstream does it.

Anyway the C++ should not be needed anymore, its up to you

[Havunen]

@octavonce Updated mimalloc sources to 3.3.2 and 2.3.2

[past-due]

Anyway the C++ should not be needed anymore, its up to you

Personally, I would advocate for compiling as C++ for MSVC, due to the current recommendations from the mimalloc author:

Well, technically msvc nowadays supports C11 and C17 -- but atomics are not quite supported yet (but available behind an experimental flag, I will try this out as well). So, generally I would still recommend using C++ mode.