STL: Consider cleaning up and numbering static_assert messages

[StephanTLavavej]

MSVC's compiler warnings and errors are numbered. Somewhat recently, we started numbering the STL's deprecation warnings. These unique numbers are searchable (and can be documented, in theory):

STL/stl/inc/yvals_core.h

Lines 676 to 681 in 6b0238d

	#define _CXX17_DEPRECATE_RESULT_OF \
	[[deprecated("warning STL4014: " \
	"std::result_of and std::result_of_t are deprecated in C++17. " \
	"They are superseded by std::invoke_result and std::invoke_result_t. " \
	"You can define _SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING " \
	"or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning.")]]

However, we haven't been numbering our static_assert messages. We have two numbered #error messages, and that's it:

STL/stl/inc/yvals_core.h

Lines 425 to 431 in 6b0238d

	#if __clang_major__ < 8 || (__clang_major__ == 8 && __clang_minor__ == 0 && __clang_patchlevel__ == 0)
	#error STL1000: Unexpected compiler version, expected Clang 8.0.1 or newer.
	#endif // ^^^ old Clang ^^^
	#elif defined(_MSC_VER)
	#if _MSC_VER < 1923 // Coarse-grained, not inspecting _MSC_FULL_VER
	#error STL1001: Unexpected compiler version, expected MSVC 19.23 or newer.
	#endif // ^^^ old MSVC ^^^

Our static_assert messages are sometimes detailed:

STL/stl/inc/type_traits

Lines 22 to 24 in 6b0238d

	template <class _Ty, _Ty... _Vals>
	struct integer_sequence { // sequence of integer parameters
	static_assert(is_integral_v<_Ty>, "integer_sequence<T, I...> requires T to be an integral type.");

And sometimes not:

STL/stl/inc/type_traits

Lines 1464 to 1466 in 6b0238d

	template <class _Ty>
	_NODISCARD constexpr _Ty&& forward(remove_reference_t<_Ty>&& _Arg) noexcept { // forward an rvalue as an rvalue
	static_assert(!is_lvalue_reference_v<_Ty>, "bad forward call");

We should consider cleaning up our static_assert messages to be uniformly detailed (with Standardese citations when possible), and numbering them. The questions that we need to answer are:

• What numbers should we use? My initial thought is to continue imitating the compiler:
  • STL1000 series for fatal errors (e.g. using an intolerably old compiler is a configuration error that needs to be fixed before dealing with anything else)
  • STL2000 series (eventually STL3000 series) for ordinary errors
  • STL4000 series (eventually STL5000 series) for warnings
• How do we ensure that numbers are uniquely used, and never reused? For warnings, we follow the conventions:

STL/stl/inc/yvals_core.h

Line 507 in 6b0238d

// STL4003 was "The non-Standard std::identity struct is deprecated and will be REMOVED."

STL/stl/inc/yvals_core.h

Line 833 in 6b0238d

// next warning number: STL4026

[AlexGuteniev]

I guess standard citation would be very useful. This makes the error sound more solid.

Numbering is not that much useful. I don't think it is useful to document these errors, as the documentation would replicate standard requirements. Still numbers will not harm. Can go as comments in <yvals_core.h> too.

I don't think it is a good idea to move the literal message in <yvals_core.h>, rather I prefer static_assert to be readable in place, and <yvals_core.h> to contain comment duplicate.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting and the consensus was:

• Numbers will be potentially useful for creating localized documentation in the future.
• The proposed numbering scheme is good:
  • STL1000 series for fatal errors (typically #errors indicating compiler configuration problems etc.)
  • STL2000 series for ordinary errors (typically static_asserts)
  • STL4000 series for warnings (including but not limited to deprecation warnings)

• To ensure unique usage, <yvals_core.h> can contain comments like the following:

// last fatal error: STL1004 "C++98 unexpected() is incompatible with C++23 unexpected<E>."
// last ordinary error: STL2000 "blah blah problem with a type blah"
// last warning: STL4039 "The contents of <coroutine> are not available with /await."

This would replace the current scheme of:

// next warning number: STL4040