Open llvmbot opened 6 years ago
IMHO nullptr_t should only have been required by
and not . That's what we did for std::byte. Too late now though. Maybe it's not too late, there seems to be support for removing it. https://wg21.link/lwg3484
There's usually support for removing things from people who won't get the bug reports when code using it breaks ;-)
That being said, we have implementation divergence, and we should resolve that.
IMHO nullptr_t should only have been required by
and not . That's what we did for std::byte. Too late now though.
Maybe it's not too late, there seems to be support for removing it. https://wg21.link/lwg3484
We do that for
and and it causes problems too often (when somebody does -I /usr/include the include order changes and include_next no longer works).
libc++ does this for 18 of the C headers; doing so seemed necessary to get the right results for the headers where C and C++ have somewhat different requirements (for instance, we are required to #undef macros that the C headers "helpfully" define that shadow libc functions). We don't consider ourselves responsible for problems caused by people misconfiguring their own include paths.
ICC has the same problem, but that's not your concern.
A simpler libstdc++ change would be to just add it to the global namespace unconditionally in <bits/c++config.h>, which is where we add it to namespace std, not in
I think that would be conforming, since any std::lib header is allowed to include
I don't much like that, but would be less unhappy if it was conditional:
--- a/libstdc++-v3/include/bits/c++config +++ b/libstdc++-v3/include/bits/c++config @@ -251,6 +251,12 @@ namespace std
}
+#if clang
+// GCC's
IMHO nullptr_t should only have been required by
Libstdc++ could provide its own
We do that for
Clang++ accepts when using libc++.
The problem is that we added this in libc++, whereas GCC added it in their compiler-specific stddef.h wrapper.
Question is, who should change? Should libstdc++ change, in that it's not providing a correct C++ standard library implementation when used with a C standard library
(We already make the latter choice on Windows platforms, where the native
IMHO nullptr_t should only have been required by and not
. That's what we did for std::byte. Too late now though.
This is supposed to say "should only have been required by \
@jwakely I read the original bug report and I'm wondering what's expected from Clang/libc++ here. It seems like the simplest fix would be for libstdc++ to declare nullptr_t
inside <stddef.h>
. Is there something actionable for LLVM here?
Extended Description
clang++ rejects the following code:
include
::nullptr_t n;
"3|error: 'nullptr_t' in namespace '::' does not name a type"
This code is supposed to be accepted, because [depr.c.headers] p2 says:
"Every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope."
Paolo Carlini has suggested to perform this change near to existing C++11-aware code in stddef.h:
if (defined (STDC_VERSION) && STDC_VERSION >= 201112L) \
|| (defined(cplusplus) && cplusplus >= 201103L)
ifndef _GCC_MAX_ALIGN_T
define _GCC_MAX_ALIGN_T
/ Type whose alignment is supported in every context and is at least as great as that of any standard type not using alignment specifiers. / typedef struct { long long max_align_ll attribute((aligned(alignof(long long)))); long double max_align_ld attribute((aligned(alignof(long double)))); } max_align_t;
endif
endif / C11 or C++11. /
BTW, I tried g++. It accepts the above code sample.