iana added a comment.
In D157757#4600357 <https://reviews.llvm.org/D157757#4600357>, @ldionne wrote:
> This is going to be really naive, but can someone explain why we need these
> `__need_XXXXX` macros? Why doesn't `<stddef.h>` simply always declare what it
> should declare? Also, does anybody understand the expected relationship
> between the C Standard Library headers and these Clang builtin headers? Who
> defines what?
>
> Everyone I've spoken to so far about this (and myself) was extremely
> confused. At some point I thought these macros were only needed for
> compatibility with old glibcs but that wouldn't even be needed anymore, but
> I'm not certain.
The `__need_` macros are to support some strict mostly POSIX behaviors like
<sys/types.h> is supposed to provide `size_t` but none of the other things in
<stddef.h>. Apple has headers like <sys/_types/_rsize_t.h> and
<sys/_types/_offsetof.h> that are expected to provide those types and nothing
else. Right now they're redeclaring the types, and if you're using clang
modules with the right flags, that's an error. So I need to switch those to
doing something like this.
#define __need_rsize_t
#include <stddef.h>
The relationship between clang's stddef.h and the C Standard Library stddef.h
is that there is no relationship. clang's header doesn't #include_next, and it
is in the search path before the OS's cstdlib.
================
Comment at: clang/lib/Headers/stddef.h:118-122
+#ifdef __cplusplus
+namespace std {
+typedef decltype(nullptr) nullptr_t;
+}
+using ::std::nullptr_t;
----------------
ldionne wrote:
> iana wrote:
> > aaron.ballman wrote:
> > > Related:
> > >
> > > https://github.com/llvm/llvm-project/issues/37564
> > > https://cplusplus.github.io/LWG/issue3484
> > >
> > > CC @ldionne
> > I don't _think_ this change actually changes the way nullptr_t gets defined
> > in C++, does it?
> I think we absolutely don't want to touch `std::nullptr_t` from this header.
> It's libc++'s responsibility to define that, and in fact we define it in
> `std::__1`, so this is even an ABI break (or I guess it would be a compiler
> error, not sure).
I'm really not touching it though. All I did is move it from `__need_NULL` to
`__need_nullptr_t`.
The old behavior is that `std::nullptr_t` would only be touched if (no
`__need_` macros were set or if `__need_NULL` was set), and (_MSC_EXTENSIONS
and _NATIVE_NULLPTR_SUPPORTED are defined).
The new behavior is that `std::nullptr_t` will only be touched if ((no
`__need_` macros are set) and (_MSC_EXTENSIONS and _NATIVE_NULLPTR_SUPPORTED
are defined)) or (the new `__need_nullptr_t` macro is set)
So the only change is that C++ code that previously set `__need_NULL` will no
longer get `std::nullptr_t`. @efriedma felt like that was a fine change.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157757/new/
https://reviews.llvm.org/D157757
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
