Fixed wrong configuration for ASIO_HAS_CO_AWAIT

[Febbe]

This adds a more general approach, to check for c++20 coroutines, which takes the feature test macros into account, defined since c++20: Proposal: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0912r5.html cppreference: https://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros#C.2B.2B20

I've kept the old macros, in the case compilers + stl-impl add the support, even, when they did not yet set the feature testing macros.
I've also made them more robust: The #elif were not mutually exclusive, so I've changed them to if !defined(ASIO_HAS_CO_AWAIT) && ...

[Febbe]

Fixes #1138

[Febbe]

Waiting for feedback, pipeline and approval. I will rebase / squash (fixup) it then.

[madhur4127]

Interesting test case

[Febbe]

Interesting test case

Can you elaborate?
Btw., to use coroutines with clang13 you must use: -Wall -Wextra -std=c++20 -stdlib=libc++. The libstdc++ does not have the header.

[madhur4127]

The problem is that using clang13 with libstdc++ will fail in a weird way.

HAS_CO_AWAIT will be true but HAS_COROUTINE is false so if you look at any header say awaitable.hpp it'll fail to find the experimental/coroutine.

there shouldn't be the missing header error.

[madhur4127]

I guess what I am trying to hint is that you should also change HAS_STD_COROUTINE to pick the right header.

[Febbe]

I guess what I am trying to hint is that you should also change HAS_STD_COROUTINE to pick the right header.

This would require another variable like ASIO_COROUTINE_HEADER, which is then set to either the plane one or the one in experimental.

[Febbe]

But in my opinion, as long as a compiler + library does not fully implement a feature (clang and coroutines), 3rd parties using the feature should concentrate on the newest compiler version, implementing the partial feature.

For example: No one actually want to use clang13 with a not fully implemented coroutine support, when there is clang16 / clang17 which fully support it (hopefully).

[madhur4127]

I'm afraid to say this but not every firm can use bleeding edge compilers.

Some firms have a rigorous process to update the compiler and they might be stuck with clang 13.

in this case we can simply check for has_co_await and then if any of coroutine or experimental/coroutine header exists we should pick the right one.

This will handle case when using clang13 with exp and non exp coro header

[Febbe]

I'm afraid to say this but not every firm can use bleeding edge compilers.

Doesn't the same apply to bleeding edge / incomplete compiler features? With that logic, no dev must be allowed to use unfinished language features of the current compiler.

I can take a look into this, but if @chriskohlhoff doesn't like it at all, it does not make sense to put more effort into this patch.