fix(windows): pair aligned delete with its allocator

[knewstimek]

Fix aligned C++ delete on Windows with the global mimalloc override.

LLVM-MinGW's C++ runtime can call the CRT import pointer __imp__aligned_free directly. The linker's --wrap=_aligned_free does not catch that call, so aligned allocation from mimalloc can reach UCRT's deallocator. The six aligned delete ABI entry points now use the owner-aware wrapper. CRT-owned aligned blocks still go through __real__aligned_free because they carry a CRT header.

This follows #2260, which changed aligned allocation. A production-flag Windows build previously faulted in _aligned_free while indexing a multi-file C++ project with parallel workers; the same index completed with this fix. The project had multiple translation units and aligned C++ allocations. The unit-test build does not enable CBM_MEM_GLOBAL_OVERRIDE, so it cannot exercise this path; the Windows production pr-smoke build is the relevant CI leg.

Split from #2268. No encoding or compile database changes.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thank you for chasing this after #2260. A fault inside _aligned_free is the kind of crash that is hard to pin down, and your explanation of the deallocator mismatch is clear.

I tried to reproduce it on our Windows ARM64 VM (MSYS2 CLANGARM64, lld) before merging, and found something I'd like to check with you:

• A production build of main (CBM_MEM_GLOBAL_OVERRIDE=1) indexed a 1,572-file C/C++ tree with parallel workers without a fault.
• In that binary, operator delete(void*, std::align_val_t) loads its target from __imp___wrap__aligned_free. That pointer leads to our __wrap__aligned_free, not UCRT's _aligned_free. The other five aligned delete entry points tail-call into it. So on this toolchain lld already rewrites the __imp__aligned_free reference, which is the reference the PR says --wrap misses.

That makes me think the difference is in the toolchain. Could you share:

1. the toolchain and linker you built with (LLVM-MinGW release or MSYS2 CLANG64, and its version, x64 I assume),
2. the crash stack, or at least the frame that called _aligned_free,
3. if you can, a public C++ project that reproduces it.

The first hunk, which sends a CRT-owned aligned block to __real__aligned_free instead of __real_free, is correct on its own: _aligned_free is the matching deallocator. We are happy to take that part as it is. For the six operator delete definitions, we'd like to know which toolchain needs them. If the release toolchain doesn't need them, they would silently replace libc++abi's own definitions for no benefit. A comment naming the toolchain that does need them would also help the next reader.

Thank you again for the careful work on the Windows allocator path.