-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Mark templates users shouldn't specialize with no_specializations attributes
#5536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
_NO_SPECIALIZATIONS
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
… it unconditional.
This marks the definition of coroutine_handle, and the declarations of generator, variant, and allocator_traits, to match their counterparts.
…at_context, which were missing.
…ts>` and `<xtr1common>`.
…ype traits I checked that everything in `<xtr1common>` is depicted by the Standard in `<type_traits>`.
Click to expand usage example:#include <chrono>
#include <type_traits>
template <class T>
struct Kitty {};
namespace std {
namespace chrono {
template <class T>
struct is_clock<Kitty<T>> : true_type {};
} // namespace chrono
} // namespace std
int main() {
static_assert(std::chrono::is_clock<Kitty<int>>::value);
}It was difficult to search the Standard but I didn't find any other occurrences of missed enforcement. Now all we have to do is remember to keep this current as we implement new features! (Oh yeah, and deal with any fallout in the internal builds and tests, which I will take care of.) |
|
Thanks to @MattStephanson for reminding me about Click to expand member class template example:#include <mdspan>
#include <memory>
template <typename T>
struct Kitty {};
namespace std {
template <typename T>
struct layout_left::mapping<Kitty<T>> {};
template <typename T>
template <typename U>
struct allocator<T>::rebind<Kitty<U>> {};
} // namespace std |
_NO_SPECIALIZATIONSno_specializations attributes
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
|
Thanks for helping users write more conformant code! 😻 🪄 📈 |
This PR marks templates users shouldn't specialize with
[[msvc::no_specializations]]or[[clang::no_specializations]], depending on the compiler.Resolves #5179.
All citations in this PR description are to WG21-N5014.
Class Templates
[namespace.std]/2 allows class template specializations by default. Exceptions:
initializer_listcompare_three_way_resultallocator_traitscoroutine_handleis_execution_policybasic_format_argbasic_format_contextbasic_format_parse_contextis_clockgeneratorrange_adaptor_closurevarianttupleunary_functionbinary_functionVariable Templates
[namespace.std]/3 forbids variable template specializations by default.
format_kinddisable_sized_sentinel_forenable_borrowed_rangedisable_sized_rangeenable_viewenable_nonlocking_formatter_optimizatione_vlog2e_vlog10e_vpi_vinv_pi_vinv_sqrtpi_vln2_vln10_vsqrt2_vsqrt3_vinv_sqrt3_vegamma_vphi_vType Traits
[meta.rqmts]/4 forbids specializing any template in
<type_traits>by default.common_typebasic_common_referenceFunction Templates
Specializing function templates is forbidden, but, following the decision made in #24, this PR doesn't touch any of them (except for
is_pointer_interconvertible_with_classandis_corresponding_memberin<type_traits>, as specializing those has always been forbidden).Notes
Relevant: llvm/llvm-project#118167 implemented this warning in libc++.