[expr.await] p5 The control flow returns to the current coroutine caller or resumer only if the coroutine is still suspended

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

[expr.await] p5 says:

The await-expression evaluates the (possibly-converted) o expression and the await-ready expression, then:

If the result of await-ready is false, the coroutine is considered suspended.
Then:

[...]
Otherwise, if the type of await-suspend is bool, await-suspend is evaluated, and the coroutine is resumed if the result is false.

If the evaluation of await-suspend exits via an exception, the exception is caught, the coroutine is resumed, and the exception is immediately rethrown ([except.throw]). Otherwise, control flow returns to the current coroutine caller or resumer ([dcl.fct.def.coroutine]) without exiting any scopes ([stmt.jump]). The point in the coroutine immediately prior to control returning to its caller or resumer is a coroutine suspend point.

Consider this example:

#include <coroutine>
#include <exception>
#include <iostream>



struct Task {
    struct promise_type {
        Task get_return_object() {
            return {std::coroutine_handle<promise_type>::from_promise(*this)};
        }
        std::suspend_never initial_suspend() { return {}; }
        std::suspend_never final_suspend() noexcept { return {}; }
        void return_void() {}
        void unhandled_exception() {}
    };

    std::coroutine_handle<promise_type> handle;

    Task(std::coroutine_handle<promise_type> h) : handle(h) {}
    ~Task() {}
};

struct SuspendOnce {
    bool await_ready() { return false; }
    bool await_suspend(std::coroutine_handle<>) { return false; }
    void await_resume() {}
};

Task my_coroutine() {
    co_await SuspendOnce{};
    std::cout<<"resume\n"; // #1
}


int main() {
    auto task = my_coroutine();
    std::cout<<"main\n";
    return 0;
}

The implementations continue to evaluate #1 without returning the control flow to the caller.

Suggested Resolution:

Otherwise, control flow returns to the current coroutine caller or resumer ([dcl.fct.def.coroutine]) without exiting any scopes ([stmt.jump]) if the coroutine is suspended

[ddvamp]

@xmh0511 Coroutine is already considered suspended in all cases under [expr.await]#5.1. It looks like [expr.await]#5.2 covers the problem you described. But 5.1 and 5.2 have some kind of wrong order, or they don't have any order at all.

Maybe you helped me see another problem. The currently suspended coroutine can be resumed before returning from the await_suspend, for example by handle.resume() inside the await_suspend. But reading 5.1 and 5.2 in this case, the coroutine does not have a suspend point "for next resumer", right? However, when the coroutine is suspended again, we will leave two await_suspend in a row, defining two suspend points in the same place, only in the wrong order, and one too late. That is, the suspend point is defined not in terms of suspending and resuming the coroutine, but in terms of returning to the caller/resumer. Correct me if I'm wrong.

[xmh0511]

But 5.1 and 5.2 have some kind of wrong order, or they don't have any order at all.

The "if... then..." structure implies the required reading order.

Coroutine is already considered suspended in all cases under [expr.await]#5.1.

It appears to me that the coroutine is never considered suspended if it is resumed, regardless of whether there is an explicit call to the member function resume or the wording states that the coroutine is resumed.

The literal meaning of "resume" is to continue to execute the coroutine.

[ddvamp]

It appears to me that the coroutine is never considered suspended if it is resumed, regardless of whether there is an explicit call to the member function resume or the wording states that the coroutine is resumed.

A couple of years ago, I started a related discussion where it was decided otherwise. You might want to take a look.
#601
llvm/llvm-project#98740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905

It may need to be reviewed again when coroutine is considered suspended.

Edit: By the way, this seems to me to be a clear indication that coroutine can be suspended and immediately resumed. (5.1): ...suspended. Then... -> (5.1.2): ...resumed...

[xmh0511]

It appears to me that the coroutine is never considered suspended if it is resumed, regardless of whether there is an explicit call to the member function resume or the wording states that the coroutine is resumed.

A couple of years ago, I started a related discussion where it was decided otherwise. You might want to take a look. #601 llvm/llvm-project#98740 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905

It may need to be reviewed again when coroutine is considered suspended.

Edit: By the way, this seems to me to be a clear indication that coroutine can be suspended and immediately resumed. (5.1): ...suspended. Then... -> (5.1.2): ...resumed...

See #865 to embody the issue via my understanding.

[ddvamp]

I'm not sure if this is an issue, but it's probably related. According to [expr.await]#1: "Suspending the evaluation of a coroutine transfers control to its caller or resumer". However, this is not always the case. And another example:

#include <coroutine>

struct Tag {
  struct promise_type {
    Tag get_return_object() { return {}; }
    std::suspend_never initial_suspend() { return {}; }
    std::suspend_never final_suspend() noexcept { return {}; }
    void return_void() {}
    void unhandled_exception() {}
  };
};

struct Awaiter {
  bool await_ready() { return false; }
  bool await_suspend(std::coroutine_handle<> h) {
    h.resume(); // Resumed
    return false; // Resumed
  }
  void await_resume() {}
};

Tag Coroutine() {
  co_await Awaiter{}; // Here coroutine is suspended, but control is not transferred to caller (StartCoro())
  co_await std::suspend_always{};
}

void StartCoro() {
  Coroutine();
}

int main() {
  StartCoro();
}

P.S. I would be glad to have an explanation of which sentences in the standard are "normative/defining", and which are like "just words in English".