[libcxx-commits] [clang] [libcxx] [Clang] Add __builtin_invoke and detect std::invoke as a builtin (PR #116709)

[Nikolas Klauser via libcxx-commits]

philnik777 wrote:

@ldionne I think this is the more appropriate place to discuss this.

(From https://github.com/llvm/llvm-project/pull/116637#discussion_r1854114956)

> Chris had a patch on Clang at some point where we discussed this and I voiced concerns. Here it is: https://reviews.llvm.org/D130867
> 
> Here are some of my concerns:
> 
>     1. Implementing more stuff in the compiler adds complexity to the compiler, and does not decrease the complexity of the library because libc++ still needs to implement invoke on other compilers.
> 
>     2. It duplicates the tests, since we need to test the builtin and the standard library interface to the same level.
> 
>     3. Duplicating functionality in libc++ and in the compiler is confusing. For instance, it sets up the stage for people not knowing where a bug in `std::invoke` should be fixed. Is it in the compiler? In the library? In both? And the set of folks who can fix a bug in the compiler is a lot smaller than the set of folks who can do that in the library.
> 
>     4. It creates another level of coupling between the library and the compiler version-wise. For example, if we have a LWG issue fixing `std::invoke`, we must now fix it in Clang and whether the issue is fixed is not something we can determine from the library, it becomes something that depends on the compiler. This is technically a pre-existing issue with the builtin type traits, but in practice the type traits have a simple API and they don't change much, unlike `std::invoke` which has a complex simplification and could be the target of changes.

1. I'm not convinced the library part is true. The reality is that we support Clang and GCC, and if they both support the builtins (or provide different ones for the same feature) we remove our fallback implementations and thus reducing the complexity for libc++. GCC 15 already adds `__is_invocable`, so we would be able to at least simplify our traits. Whether the complexity is too high for the compiler is something the compiler maintainers should judge IMO. FWIW IMO The compiler implementations is actually much easier to understand than the mess we have in the library.

2. True. I'm not sure this is a huge burden though.

3. IMO that's not the case. We call a builtin. If that builtin is wrong we file a bug against the compiler. I don't really see the confusion here. It's exactly the same as with type traits.

4. I don't think this is just "technically pre-existing". There are bugs in the compiler builtins. In some cases we've waited until these bugs are fixed to use a builtin trait, but when the bug was pre-existing for a significant amount of time we didn't bother trying to work around it in the library. I'm not sure what you mean by "complex simplification".

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