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

[Louis Dionne via libcxx-commits]

ldionne wrote:

> 
> 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.

Does GCC implement (or have plans to implement) `__builtin_invoke`?

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

Well, our tests for `std::invoke` are not simple, and we'd have to do the same in Clang if we want to have the same amount of coverage.

> 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.

Your PR description says that the compiler recognizes `std::invoke` itself as a builtin, is that right? It makes a difference to me whether `std::invoke` is a builtin directly or `std::invoke` calls `__builtin_invoke`.

> 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".

Sorry, I meant complex specification. I mean that `invoke` is not like `is_constructible` -- it may be updated in the future. The updates would be to the library wording, and I'd find it really weird to have to go change the compiler builtin to account for what's effectively a library change.


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