[clang] [Headers] Don't declare unreachable() from stddef.h in C++ (PR #86748)

[Louis Dionne via cfe-commits]

ldionne wrote:

> > Thanks for the explanation, @AaronBallman . I think I am generally deeply confused about what should be provided by the compiler and what should be provided by the C Standard Library on any given platform. From your reply, it looks like there's no clear rule and Clang basically provides anything that seems "easy enough" to provide. I still don't understand how that works in case you do end up including a header from the platform that (re)defines `unreachable`, for example.
> 
> For C17 and earlier, the rule was that we provided everything required for freestanding by the standard, and anything else the user wanted had to come from a library the user supplied. For C23, which we're still in the process of implementing, the situation is different and we've not documented what the expectations are yet. I suspect we're going to end up requiring the user to provide their own freestanding library implementation and the compiler will provide only the bits that the compiler has to provide (things like `limits.h`).

Thanks, this clarifies a lot of things in my head.

> 
> Definitely agreed that we need to document this, but we need to figure out what we want to document in the first place -- some of this is new-ish territory because of the additional interfaces. `unreachable` is morally similar to `offsetof` in that it's a macro interface where the implementation can give better results by expanding to a builtin than a library is likely to be able to give via a naive implementation, but the interfaces _can_ be provided by a CRT. So which one _should_ win? Today, if something else defined `offsetof` or `unreachable` before including `stddef.h`, Clang's headers won't bother re-defining the macro.
> 
> I think we may need to look at what existing freestanding CRTs and hosted CRTs expect to help give us a path forward?

Personally, my naive take on this is that Clang should basically define the least amount of things from the C Standard Library, and let a proper C Standard Library implement it. Having interacted with a good number of folks who work on C libraries (including embedded flavors), I think they all expect that they need to provide basically all the declarations/definitions in the C Standard, except perhaps stuff from `<stdarg.h>` and a few other oddities. Doing otherwise and trying to be "helpful" in Clang only creates confusion and forces C libraries to jump through hoops to avoid colliding with stuff already defines in Clang builtin headers.

A C library is not super complicated in the first place, so I don't think we're saving a lot of people a lot of time by trying to give them a few definitions here and there. Additionally, there's many freestanding-friendly C libraries around so it's not like most people have to write their own.

That's just my immediate reaction to this. It's pretty naive but at this specific point I believe we should basically not provide any Clang builtin headers except the ones that clearly provide compiler-related stuff (e.g. `<stdarg.h>` or `tmmintrin.h` & friends). I'm eager to hear other people's takes on this.

SLA note: I'll be OOO for a few days so I'll only see replies early next week.

https://github.com/llvm/llvm-project/pull/86748