assigned to @ldionne

For added fun, you have a potential ABI break:

#include
struct A : std::allocator { };
static_assert( std::is_trivially_default_constructible::value, "" );
static_assert( std::is_trivial::value, "" );

This passes in C++17 and earlier, but not in C++20:

a.C:5:1: error: static_assert failed due to requirement 'std::is_trivially_default_constructible::value' ""
static_assert( std::is_trivially_default_constructible::value, "" );
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.C:6:1: error: static_assert failed due to requirement 'std::is_trivial::value' ""
static_assert( std::is_trivial::value, "" );
^ ~~~~~~~~~~~~~~~~~~~~~~~~~

Your primary template for std::allocator has a non-trivial default constructor (for C++03 compat, just like GCC's one does) and so when allocator uses the primary template, it also has a non-trivial default ctor. In C++17 the explicit specialization for allocator has a trivial default ctor.

I don't know if you care about this case.

This warning is misleading and unhelpful. It's true that the explicit
specialization is deprecated in C++17 and gone in C++20, but that doesn't
mean users can't use std::allocator in C++20. It just means that doing
so uses the primary template.

This was even called out in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html#3.9

"Removing the explicit specialization, per the proposed resolution below, should no impact on that, as the primary template will now provide the correct behavior."

The intention is that allocator continues to be usable by programs, all that changes is how the library defines it. And so giving users a diagnostic is wrong.

You're right, but for our defence, https://wg21.link/p0174#2.2 did deprecate the specialization, and I'm not seeing any discussion saying something like "but oh, users should still be able to use it". The intent appears to be pretty unclear if you read only that paper, and you actually need to read the fine print in wg21.link/p0619r4#3.9 to know the intent.

Am I missing something or that's messed up?

For added fun, you have a potential ABI break:

I think that is unlikely to bite anyone.

https://reviews.llvm.org/D104323

I'm also trying to backport this to LLVM 12.0.1 because I think this is a pretty vexing issue: https://reviews.llvm.org/D104324

commit 87784cc
Author: Louis Dionne ldionne.2@gmail.com
Date: Tue Jun 15 16:08:38 2021 -0400

[libc++] Undeprecate the std::allocator<void> specialization

While the std::allocator<void> specialization was deprecated by
https://wg21.link/p0174#2.2, the *use* of std::allocator<void> by users
was not. The intent was that std::allocator<void> could still be used
in C++17 and C++20, but starting with C++20 (with the removal of the
specialization), std::allocator<void> would use the primary template.
That intent was called out in wg21.link/p0619r4#3.9.

As a result of this patch, _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
will also not control whether the explicit specialization is provided or
not. It shouldn't matter, since in C++20, one can simply use the primary
template.

Fixes llvm/llvm-project#49643 

Differential Revision: https://reviews.llvm.org/D104323

I also created a patch for fixing the triviality difference between C++20 and previous standard modes at https://reviews.llvm.org/D104398.

The fix does not apply cleanly, could someone backport this and push a branch to their local github fork?

The fix does not apply cleanly, could someone backport this and push a
branch to their local github fork?

This has already been merged to release/12.x:

commit e7dac56
Author: Louis Dionne ldionne.2@gmail.com
Date: Tue Jun 15 17:55:27 2021 -0400

[🍒][libc++] Un-deprecate std::allocator<void>

This is a cherry-pick of 87784cc6fb3453a17e0e78 on 'main' for
backporting to LLVM 12.

Differential Revision: https://reviews.llvm.org/D104324

I'm a bit confused. Isn't Table 35 saying that in order for X<T> to be a valid allocator, T must be an object type? How does std::allocator<void> satisfy that requirement?