[libc++] `std::vector<char[16]>` error: cannot initialize return object of type `char *[16]` with an rvalue of type `char *`

[AngryLoki]

According to https://stackoverflow.com/a/63259370/337979, the following code should work since c++11:

#include <vector>

void test(){
	std::vector<char[16]> alpha(10);
	static_assert(sizeof(alpha[0]) == 16, "Size of each element in alpha is not 16 bytes");
}

It works with libstdc++ (both in gcc/clang), but fails with libc++: https://godbolt.org/z/qnn1Kehz4

$ clang++ -std=c++23 --stdlib=libstdc++ main.cpp -c -o main.o
# ok!

$ clang++ -std=c++23 --stdlib=libc++ main.cpp -c -o main.o
In file included from main.cpp:1:
In file included from /usr/include/c++/v1/vector:308:
In file included from /usr/include/c++/v1/__algorithm/copy.h:12:
In file included from /usr/include/c++/v1/__algorithm/copy_move_common.h:18:
In file included from /usr/include/c++/v1/__string/constexpr_c_functions.h:14:
/usr/include/c++/v1/__memory/construct_at.h:41:10: error: cannot initialize return object of type 'char *[16]' with an rvalue of type
      'char *'
   41 |   return ::new (std::__voidify(*__location)) _Tp(std::forward<_Args>(__args)...);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/__memory/construct_at.h:49:15: note: in instantiation of function template specialization
      'std::construct_at<char[16], char *>' requested here
   49 |   return std::construct_at(__location, std::forward<_Args>(__args)...);
      |               ^
/usr/include/c++/v1/__memory/allocator_traits.h:305:10: note: in instantiation of function template specialization
      'std::__construct_at<char[16], char *>' requested here
  305 |     std::__construct_at(__p, std::forward<_Args>(__args)...);
      |          ^
/usr/include/c++/v1/vector:1057:21: note: in instantiation of function template specialization
      'std::allocator_traits<std::allocator<char[16]>>::construct<char[16], void, void>' requested here
 1057 |     __alloc_traits::construct(this->__alloc(), std::__to_address(__pos));
      |                     ^
/usr/include/c++/v1/vector:1122:5: note: in instantiation of member function 'std::vector<char[16]>::__construct_at_end' requested here
 1122 |     __construct_at_end(__n);
      |     ^
main.cpp:4:24: note: in instantiation of member function 'std::vector<char[16]>::vector' requested here
    4 |         std::vector<char[16]> alpha(10);
      |                               ^
1 error generated.

It looks similar to #40629, but probably different as char[16] is trivially destructible.

Checked with clang version 18.1.8+libcxx and libcxx-18.1.8. Discovered in https://github.com/ROCm/hipBLASLt/blob/f192cdec31dbdca581c8df03c3980b9cc5b678c7/library/src/amd_detail/rocblaslt/src/rocblaslt_mat.cpp#L605

[frederick-vs-ja]

This (for C++20 and later modes) is LWG3436 - currently std::vector<char[16]> alpha(10); is made ill-formed by the use of construct_at (by P0784R7 adopted for C++20).

The error is arguably "by design" in C++20 and later, but at least I think this program should be well-formed in C++11~17. So libc++ is probably buggy in old modes (Godbolt link),

[frederick-vs-ja]

It seems that we should just make __construct_at return void, which will fix this issue for pre-C++20 modes.

llvm-project/libcxx/include/__memory/construct_at.h

Lines 46 to 54 in 98ebdd0

	template <class _Tp, class... _Args, class = decltype(::new(std::declval<void*>()) _Tp(std::declval<_Args>()...))>
	_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _Tp* __construct_at(_Tp* __location, _Args&&... __args) {
	#if _LIBCPP_STD_VER >= 20
	return std::construct_at(__location, std::forward<_Args>(__args)...);
	#else
	return _LIBCPP_ASSERT_NON_NULL(__location != nullptr, "null pointer given to construct_at"),
	::new (std::__voidify(*__location)) _Tp(std::forward<_Args>(__args)...);
	#endif
	}

The only one place using the return value of __construct_at is here:

llvm-project/libcxx/include/__memory/uses_allocator_construction.h

Lines 210 to 216 in 98ebdd0

	template <class _Type, class _Alloc, class... _Args>
	_LIBCPP_HIDE_FROM_ABI constexpr _Type*
	__uninitialized_construct_using_allocator(_Type* __ptr, const _Alloc& __alloc, _Args&&... __args) {
	return std::apply(
	[&__ptr](auto&&... __xs) { return std::__construct_at(__ptr, std::forward<decltype(__xs)>(__xs)...); },
	std::__uses_allocator_construction_args<_Type>(__alloc, std::forward<_Args>(__args)...));
	}

However, if I understand correctly, __uninitialized_construct_using_allocator is only used in the C++20 component uninitialized_construct_using_allocator (and not SFINAE-friendly),

llvm-project/libcxx/include/__memory/uses_allocator_construction.h

Lines 234 to 239 in 98ebdd0

	template <class _Type, class _Alloc, class... _Args>
	_LIBCPP_HIDE_FROM_ABI constexpr auto
	uninitialized_construct_using_allocator(_Type* __ptr, const _Alloc& __alloc, _Args&&... __args)
	-> decltype(std::__uninitialized_construct_using_allocator(__ptr, __alloc, std::forward<_Args>(__args)...)) {
	return /*--*/ std::__uninitialized_construct_using_allocator(__ptr, __alloc, std::forward<_Args>(__args)...);
	}

So I think we should:

• move the body of __uninitialized_construct_using_allocator into uninitialized_construct_using_allocator with std::construct_at unconditionally used, and then remove __uninitialized_construct_using_allocator. and
• make __construct_at return void.

@philnik777 What do you think?

[ldionne]

In more recent patches (including trivial relocation patches that haven't landed yet), we do want to use the return value of __construct_at. Since this is explicitly invalid in C++20 and above, I am not certain that we'd be making our users a service by making it compile in C++11-17 but then fail in C++20 and above. However, making it fail consistently in all Standard modes makes it easier for people to actually migrate to newer standard modes, which we want to encourage.

This is arguably a bit of a relaxed interpretation of the Standard for the purpose of providing the "most consistent behavior" across Standard modes. We don't normally take that stance (usually we go for strict conformance). If you disagree with this conclusion (you'd be right to), please reopen and we'll see how to be more conforming in 11-17.

[frederick-vs-ja]

Since this is explicitly invalid in C++20 and above, I am not certain that we'd be making our users a service by making it compile in C++11-17 but then fail in C++20 and above.

Ah, LWG3436 is recently accepted and makes this valid.

[frederick-vs-ja]

@AngryLoki @ldionne I think I was confused by the answer on stackoverflow.

TL; DR: vector<T[N]> should be valid since C++20 as corrected by LWG3436, but not before C++20.

1. In C++98, element type was required to be Assignable (which corresponds to Cpp17CopyAssignable since C++20). So array types are not permitted to be container element types.
2. In C++11, the requirement was changed to Erasable (renamed to Cpp17Erasable later). For containers using the default std::allocator, array types are still not permitted. But array types might be Cpp17DefaultInsertable since then.
3. In the original C++20, P0784R7 made the default mechanisms of std::allocator_traits properly destroy array types, but broke the construction.
4. LWG3436 made the (default) construction valid again, so the example should be accepted.

[ldionne]

Thanks for the analysis! So basically we should implement LWG3436 and we'll be conforming.