These types of compiler crashes were supposed to be fixed in the current Apple branch of LLVM but it looks like their fix doesn't work on all platforms. I investigated the cause and made a temporary workaround, which is *not* the right way to solve it, but nonetheless works enough for the purpose, until the LLVM team addresses it more properly.

The reason is that when vector containers need to be resized, sometimes the memory allocator needs to move the container (in case the new requested size exceeds the available free space after the currently allocated space - a typical case of memory fragmentation handling). Due to different assumptions on how memory allocators are supposed to work across platforms, a debug assertion would fail on Windows and not on other platforms. I assumed that references to moved data would still be valid if made just after the move, which seemed to be the case here, so I just disabled that assertion (which would nonetheless have been disabled in "full release mode", i.e. if clang was compiled with the NDEBUG flag, which I do not - I prefer a compiler that crashes more often and tells why, than one that crashes less but produces garbage and never tells anything).

I'll be uploading a new version of the builder (3.35.4) with that patch today.

:: @Pierre-Marie Baty added on 10 Jun ’21 · 12:32

The symptom was: you build a project and the build fails during compilation step with a lot of errors, of which the first one says something like:

% build log:
assertion failed: isSafeToReferenceAfterResize(Elt, NewSize) && "Attempting to reference
an element of the vector in an operation " "that invalidates it"
%

If you were getting that sort of failure, version 3.35.4 should fix it.