Mark templates users shouldn't specialize with _NO_SPECIALIZATIONS

[localspook]

This PR marks templates users shouldn't specialize with [[msvc::no_specializations]] or [[clang::no_specializations]], depending on the compiler.

Resolves #5179.

The rule goes [namespace.std]:

• Specializing class templates is allowed, with the exception of:

  • initializer_list
  • allocator_traits
  • coroutine_handle
  • compare_three_way_result
  • is_execution_policy
  • basic_format_arg
  • is_clock
  • generator
  • range_adaptor_closure
  • variant
  • tuple
  • unary_function
  • binary_function

• Specializing variable templates is forbidden, with the exception of:

  • format_kind
  • disable_sized_sentinel_for
  • enable_borrowed_range
  • disable_sized_range
  • enable_view
  • enable_nonlocking_formatter_optimization
  • e_v
  • log2e_v
  • log10e_v
  • pi_v
  • inv_pi_v
  • inv_sqrtpi_v
  • ln2_v
  • ln10_v
  • sqrt2_v
  • sqrt3_v
  • inv_sqrt3_v
  • egamma_v
  • phi_v

• Specializing any template in <type_traits> is forbidden, with the exception of:

  • common_type
  • basic_common_reference

• Specializing function templates is forbidden, but, following the decision made in P0551R3 Thou Shalt Not Specialize std Function Templates! #24, this PR doesn't touch any of them (except for is_pointer_interconvertible_with_class and is_corresponding_member in <type_traits>, as specializing those has always been forbidden).

Relevant: PR implementing this warning in libc++

[localspook]

Adding the macro here is needed to avoid incorrect formatting like:

-struct _NO_SPECIALIZATIONS enable_if {};
+struct _NO_SPECIALIZATIONS enable_if{};

[localspook]

This PR doesn't include tests because I'm not sure how to implement them; unless I missed something, the std testing suite has no examples of tests verifying that a warning is triggered or compilation fails (only that a warning is not triggered, or compilation succeeds).

[localspook]

CI is failing because libcxx/test/std/iterators/iterator.requirements/iterator.concepts/iterator.concept.readable/indirectly_readable.compile.pass.cpp triggers UB by specializing common_reference (they're aware of this):
https://github.com/llvm/llvm-project/blob/c8f29e3b319f2324d79d350f4c0aa86c178119e6/libcxx/test/std/iterators/iterator.requirements/iterator.concepts/iterator.concept.readable/indirectly_readable.compile.pass.cpp#L143-L147
I think the solution is to specialize basic_common_reference instead, but I'll look into it and open a PR against libc++ tomorrow.

[AlexGuteniev]

CI is failing because libcxx/test/std/iterators/iterator.requirements/iterator.concepts/iterator.concept.readable/indirectly_readable.compile.pass.cpp triggers UB by specializing common_reference (they're aware of this):

I'd suggest adding to /tests/libcxx/expected_results.txt for now, so that the PR would otherwise pass CI

[frederick-vs-ja]

Pedantically speaking, program-defined specialization of allocator_traits is only forbidden since C++23. But it's possibly a good thing to "extend" the restriction to old modes.

[localspook]

There's a clear migration path that's valid in all modes (define the relevant members in the allocator class), which could be an argument for extending the restriction.

[frederick-vs-ja]

This is only necessary for Clang. MSVC and EDG can forbid program-defined initializer_list specializations themselves.

[localspook]

Done

[localspook]

I'd suggest adding to /tests/libcxx/expected_results.txt for now, so that the PR would otherwise pass CI

Done

[localspook]

I discovered that specializing unary_function and binary_function (before they were removed) is also forbidden, so I’ve marked those and added them to the PR message.

[StephanTLavavej]

/azp run STL-CI

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).