The following code causes MSVC to run out of memory and crash (when x86-native; x64-native can get away with allocating more memory but it still appears to be infinite). Interestingly, Clang also gets trapped here, although it doesn't run out of memory. I suspect that this leads to infinite constraint recursion, which may be something we need to fix either in the Standard or our implementaton.

C:\Temp>"C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Auxiliary\Build\vcvarsall.bat" x86
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.8.0-pre.6.0
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'

C:\Temp>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33129 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>clang-cl -v
clang version 16.0.5
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\bin

C:\Temp>type meow.cpp

#include <array>
#include <ranges>
#include <span>
#include <string>
using namespace std;

void TestFn(span<const wchar_t> str) {
    auto split = str | views::split('.');

    auto vals = split | ranges::to<array<wstring, 4>>();
}

C:\Temp>cl /EHsc /nologo /W4 /std:c++latest /MTd /Od /c meow.cpp
meow.cpp
C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.38.33129\include\type_traits(1430): fatal error C1060: compiler is out of heap space

C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++latest /MTd /Od /c meow.cpp
[*** RUNS FOREVER ***]

This code works with vector<wstring> as an argument for ranges::to.

VS 2022 17.8 Preview 6 type_traits 1430 is this line in main right now:

This is part of our horrible workaround for DevCom-10095944 VSO-1577508 which I've pinged the compiler team about just now, but the fact that Clang gets trapped even though it doesn't use this workaround indicates to me that the problem lies elsewhere.

Thanks to David Lowndes for the report.