P0912R5 Library Support For Coroutines

[StephanTLavavej]

P0912R5 Library Support For Coroutines

Feature-test macro as of LWG-3393 "Missing/incorrect feature test macro for coroutines":
#define __cpp_lib_coroutine 201902L

The compiler feature-test macro is __cpp_impl_coroutine defined to be 201902L.

[CaseyCarter]

From #100: Ideally <coroutine> should support both Clang and MSVC, unlike <experimental/coroutine> which has historically supported only MSVC due to differences in coroutine frame ABI.

[luncliff]

Hi, I'm already handling this issue with some tricks.
Indeed there is a gap between 2 compilers, but I could solve the issue after some trials.

And I'm maintaining build for both clang-cl and MSVC in my project.
I wish I can make a contribution for this part.

using procedure_t = void (*)(void*);

// - Note
//      MSVC coroutine frame's prefix
//      Reference <experimental/resumable> for the detail
// - Layout
//      | Promise(?) | Frame Prefix(16) | Local variables(?) |
struct msvc_frame_prefix final {
    procedure_t factivate;
    uint16_t index;
    uint16_t flag;
};
static_assert(aligned_size_v<msvc_frame_prefix> == 16);

// - Note
//      Clang coroutine frame's prefix
// - Layout
//      | Frame Prefix(16) | Promise(?) | ? | Local variables(?) |
struct clang_frame_prefix final {
    procedure_t factivate;
    procedure_t fdestroy;
};
static_assert(aligned_size_v<clang_frame_prefix> == 16);

With the known layout, I used constexpr if to select the compilers' intrinsic appropriately.
The following part is a shorten version of my workaround.

template <>
class coroutine_handle<void> {
    union prefix_t {
        void* v{};
        msvc_frame_prefix* m;
        clang_frame_prefix* c;
    };
    static_assert(sizeof(prefix_t) == sizeof(void*));
    prefix_t prefix;

    explicit operator bool() const noexcept {
        return prefix.v != nullptr;
    }
    void resume() noexcept(false) {
        if constexpr (is_msvc) {
            _coro_resume(prefix.m);
        } else if constexpr (is_clang) {
            __builtin_coro_resume(prefix.c);
        }
    }
    void destroy() noexcept {
        if constexpr (is_msvc) {
            _coro_destroy(prefix.m);
        } else if constexpr (is_clang) {
            __builtin_coro_destroy(prefix.c);
        }
    }
    bool done() const noexcept {
        if constexpr (is_msvc) {
            return _coro_finished(prefix.m);
        } else if constexpr (is_clang) {
            return __builtin_coro_done(prefix.c);
        } else {
            return false;
        }
    }
    // ...
};

With my experience, to provide a portable header for clang-cl,
the simplest way is to add some inline functions to redirect MSVC's intrinsic to Clang's intrinsic. Just like the code below.

#if defined(__clang__)

inline bool _coro_finished(msvc_frame_prefix* m) noexcept {
    auto* c = reinterpret_cast<clang_frame_prefix*>(m);
    return __builtin_coro_done(c) ? 1 : 0;
}
inline size_t _coro_resume(void* addr) {
    auto* c = reinterpret_cast<clang_frame_prefix*>(addr);
    __builtin_coro_resume(c);
    return 0;
}
inline void _coro_destroy(void* addr) {
    auto* c = reinterpret_cast<clang_frame_prefix*>(addr);
    __builtin_coro_destroy(c);
}

#elif defined(_MSC_VER)

inline bool _coro_finished(const msvc_frame_prefix* prefix) noexcept {
    return prefix->index == 0;
}

#endif

Will be glad if I can hear from you.

[CaseyCarter]

Hi, I'm already handling this issue with some tricks.

This works with either compiler, but I suspect not with both. If I link together MSVC- and Clang-compiled TUs that use coroutines, or pass a coroutine handle from a TU compiled with one compiler into a TU compiled with the other, I'd expect bad things to happen due to violating the One Definition Rule.

[sylveon]

Personally I ended up shipping libc++'s implementation with my code. ABI compat between Clang and MSVC didn't matter, because my whole codebase is built with a single compiler. I ended up ditching Clang and stopping to ship the libc++ header at some point due to other unrelated problems with Clang, but your solution certainly is interesting.

[luncliff]

Casey Carter (@CaseyCarter) I'm not sure I can test the case (linking object from both clang-cl and MSVC), but will try ASAP.
For me, the requirement for both compilers seems worthy since doing so might allow the future <coroutine> to have GCC compatibility.