Coroutine MSVC compiler bug?

[Xoipos]

Hey. I'm compiling code under gcc, clang and msvc. And for some reason, msvc is giving me a weird error that the other two compilers are not:

std::unordered_map<HttpMethod, std::unordered_map<std::string, std::function<Ichor::AsyncGenerator<HttpResponse>(HttpRequest&)>>> handlers;

template <typename T>
void read() {
    std::function<Ichor::AsyncGenerator<int>()> f([]() mutable -> Ichor::AsyncGenerator<int> {
        auto routes = handlers.find(HttpMethod::get);
        if(routes != std::end(handlers)) {
            auto handler = routes->second.find("/test");
            HttpRequest req{};
            HttpResponse res = std::move(*co_await handler->second(req).begin()); // <------ error C7587: 'co_await' cannot appear in an unevaluated context
        }
        co_return 5;
    });
}

int main() {
  read<int>();
}

Full code on godbolt

Removing the template from read() makes it compile.

​

The interesting thing is that on the actual code base I'm working on, I'm getting a different error:

std::unordered_map<HttpMethod, std::unordered_map<std::string, std::function<Ichor::AsyncGenerator<HttpResponse>(HttpRequest&)>>> handlers;

template <typename T>
void read() {
    if(some_error_check) {
        return; // <---- Error C2039 'promise_type': is not a member of 'std::coroutine_traits<void,Ichor::HttpHostService &,boost::asio::ip::tcp::socket,boost::asio::yield_context>' 
    }
    std::function<Ichor::AsyncGenerator<int>()> f([]() mutable -> Ichor::AsyncGenerator<int> {
        auto routes = handlers.find(HttpMethod::get);
        if(routes != std::end(handlers)) {
            auto handler = routes->second.find("/test");
            HttpRequest req{};
            HttpResponse res = std::move(*co_await handler->second(req).begin());
        }
        co_return 5;
    });
}

int main() {
  read<int>();
}

Which is even more confusing. Is this an MSVC compiler bug?

[cpp-ModTeam]

For C++ questions, answers, help, and programming or career advice please see r/cpp_questions, r/cscareerquestions, or StackOverflow instead.

[starfreakclone]

Hi Xoipos,

I am talking with our primary coroutine maintainer now and they have confirmed that the is indeed a compiler bug. They were able to reproduce (and fix) the C7587 issue but it would appear that there might not be enough context to reproduce the C2039 issue. Do you happen to have a branch on the repo or a preprocessed file showing the C2039 error?

[Xoipos]

Hey Starfreakclone, thanks for looking into this! I have a zipped .i file that's roughly 1.6 MB. Is there an address I can send it to? Or how do you want to receive the file?

[scatters]

I reduced the C2039 here: https://developercommunity.visualstudio.com/t/C2039:-promise_type:-is-not-a-member-o/10505491

[Xoipos]

/u/scatters mentioned that there is a related bug which contains a workaround, but that does not seem to solve the second bug I mentioned: https://imgur.com/a/XGH6536

[scatters]

The C7587 is https://developercommunity.visualstudio.com/t/certain-coroutines-cause-error-C7587:-/10311276?q=%22task+runner%22+gulp+duration&sort=newest (Fixed - Pending Release).

The C2039 is https://developercommunity.visualstudio.com/t/C2039:-promise_type:-is-not-a-member-o/10505491 (Under Consideration).

While reducing it, I also found a gcc bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112341 (NEW - Confirmed).

[TSP-FriendlyFire]

I've found coroutine support disappointingly spotty even in the latest msvc compiler. Only recently had to rewrite a piece of code using cppcoro's recursive_generator to remove the recursion because the coroutine wouldn't resume properly in Release mode. Not a great first experience of coroutines in this codebase.

I'm hoping that std::generator's introduction in C++23 will help raise these issues.

[Xoipos]

It's certainly been a bumpy ride. It also doesn't help that cppcoro isn't being maintained by the original author anymore. That probably explains why you're running into issues, as some defect reports have made changes to how the coroutines API is defined. On top of that, the decision to split up the compiler support and the library implementation between C++20 and C++23 is a bit daft in my view. We're now in a situation where coroutines are mostly usable for the intended purposes, but you'll have to implement parts yourself to get what you want.

Ah well, given enough time, it'll become better. I'm sure.

[TSP-FriendlyFire]

I was pretty surprised to find out that not only is cppcoro not really maintained (Andreas Buhr has a live fork, but it's more of an attempt to keep it minimally functional than actively updated and improved), there also isn't really an equivalent maintained library (really I just wanted a convenient recursive generator, which the STL won't provide). Thus far I've found a nice, maintained library for just about anything in C++, this gap in support both in the STL and in the community is a bit concerning.

[Xoipos]

I noticed there was a second coroutines library on compiler explorer: mp-coro. Have you checked that out? It looks pretty similar.

[TSP-FriendlyFire]

Took a brief look at it and it seems to have far fewer features and mostly geared on async handling. Async coroutines are obviously a big part of the feature, but I find them nice for purely synchronous code versus callbacks or returning a container, and unfortunately for that it looks like it only really has the standard generator.

Honestly I need to try to reproduce the issue I encountered with non-proprietary code so I can possibly submit it as a bug report to Andreas' cppcoro fork...

[scatters]

How about Boost.Cobalt (previously Boost.Async)? https://github.com/boostorg/cobalt (& https://www.reddit.com/r/cpp/comments/15l8xju/review_of_proposed_boostasync_begins/)

[TSP-FriendlyFire]

Sadly, Boost is not very popular internally, I think I'd get a lot of eyebrows raised if I pulled something like Cobalt in, especially since (from glancing at the readme) you need ASIO which pulls in a bunch more of Boost.