[PATCH] D157757: [Headers] Replace __need_STDDEF_H_misc with specific __need_ macros

[Ian Anderson via Phabricator via cfe-commits]

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