`<format>`: `std::vformat_to` results in exception in `__msvc_string_view.hpp!_Verify_offset` in version 14.44

[old-pigeon]

Describe the bug

Using a std::formatter with the 14.44 version of the STL throws at __msvc_string_view.hpp#L1280 when used with std::vformat_to and a second argument that follows after which is asked to be formatted, i. e. with :X.
The same code worked with 14.37. I both tested this with MSVC and with Clang 20, both throw with 14.44.

Command-line test case

#include <string>
#include <format>
#include <filesystem>

template <>
struct std::formatter<std::filesystem::path, wchar_t>
{
	constexpr auto parse(basic_format_parse_context<wchar_t>& context)
	{
		return context.end();
	}

	template <typename FormatContext>
	auto format(std::filesystem::path path, FormatContext& context) const
	{
		auto actual_path = path.wstring();

		return std::vformat_to(context.out(), L"\"{}\"", std::make_wformat_args(actual_path));
	}
};

int main()
{
	uint32_t actualErrorCode = 0xDEADBEEF;
	std::filesystem::path test{ "test" };
	wchar_t dest[256] = { '\0' };

	//                         v when not having :X here, it does not throw
	std::vformat_to(dest, L"{}{:X}", std::make_wformat_args(test, actualErrorCode));
	std::printf("%ls", dest);

	return 0;
}

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe /c /ZI /JMC /nologo /W3 /WX- /diagnostics:column /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /std:c++latest /permissive- /Fo"repro\x64\Debug\\" /Fd"repro\x64\Debug\vc143.pdb" /external:W3 /Gd /TP /FC /errorReport:prompt repro.cpp

Expected behavior

The output should be "test"DEADBEEF.

STL version

Microsoft Visual Studio Community 2022
Version 17.14.8

Additional context

[frederick-vs-ja]

The parse function of your formatter seems wrong. It consumes the whole remaining format string, even after the unmatched }. So it renders the parsing in some inconsistent state, in other words, causes UB, for this example.

Moreover, you're not allowed to customize std::formatter<std::filesystem::path, wchar_t>, as this specialization is entirely controlled by the implementation. You can create a wrapper for std::filesystem::path and format it.

I think we will be able to format std::filesystem::path soon, but only since C++26. See #4517.

[old-pigeon]

Thanks for your response. I'm no C++ expert by any means, however here's my response:

The author of the fmt library and later maintainer of std::format (vitaut) is active on StackOverflow and commented on a similar example, which uses the same "pattern": https://stackoverflow.com/questions/59909102/stdformat-of-user-defined-types/59909435#59909435. I would have assumed he wouldn't break the parse() function of the formatter.

Even if I am not allowed to customize anything related to std::filesystem::path, the same issue appears with a complete custom type that I 100% control. I only chose std::filesystem::path here to make it easy to understand. Please take the following example, which throws the same exception:

#include <string>
#include <format>
#include <filesystem>

struct test_type
{
	uint32_t value;
};

template <>
struct std::formatter<test_type, wchar_t>
{
	constexpr auto parse(basic_format_parse_context<wchar_t>& context)
	{
		return context.end();
	}

	template <typename FormatContext>
	auto format(test_type test, FormatContext& context) const
	{
		return std::vformat_to(context.out(), L"\"{}\"", std::make_wformat_args(test.value));
	}
};

int main()
{
	uint32_t actualErrorCode = 0xDEADBEEF;
	test_type test{ 2 };
	wchar_t dest[256] = { '\0' };

	//                         v when not having :X here, it does not throw
	std::vformat_to(dest, L"{}{:X}", std::make_wformat_args(test, actualErrorCode));
	std::printf("%ls", dest);

	return 0;
}

[frederick-vs-ja]

I would have assumed he wouldn't break the parse() function of the formatter.

This doesn't clearly seem true to me. Victor Zverovich (@vitaut) Is a "consuming-all" parse function supposed to be valid?

The following-up edits only simplified the format function and added const to it according to LWG-3636.

[cpplearner]

The formatter is required to ([formatter.requirements]):

Parses format-spec ([format.string]) for type T in the range [pc.begin(), pc.end()) until the first unmatched character. Throws format_error unless the whole range is parsed or the unmatched character is }.

And a format-spec must not start with } ([format.string.general]):

format-spec:
as specified by the formatter specialization for the argument type; cannot start with }

That is, the formatter's parse function must either return context.begin() when the replacement field is {} (which indicates that the format-spec is empty), or throw format_error. It is not expected to return context.end().

[cpplearner]

IIUC, before VS 2022 17.10, MSVC STL's vformat_to doesn't care about the return value of formatter::parse when the replacement field is {}, because it doesn't call formatter::parse at all in this case. This got fixed by #4078 and #4640.

[vitaut]

Is a "consuming-all" parse function supposed to be valid?

No because it will consume the closing }. I fixed the broken StackOverflow example.

[old-pigeon]

I can confirm that changing from .end() to .begin() in parse() fixes the underlying problem. Thank you!

This is not a bug then, sorry for bothering you.