Proposed resolution (approved by CWG 2022-06-17):

(updated according to 2022-05-20, 2022-06-03, and 2022-06-17 CWG guidance)

Change in 9.5.4 [dcl.fct.def.coroutine] paragraph 9 as follows:

... The allocation function's name is looked up by searching for it in the scope of the promise type.

• If the search finds any declarations are found, overload resolution is performed on a function call created by assembling an argument list. The first argument is the amount of space requested, and has is a prvalue of type std::size_t. The lvalues p1 ... pn are the succeeding successive arguments. Otherwise, a search is performed in the global scope. If no viable function is found (12.2.3 [over.match.viable]), overload resolution is performed again on a function call created by passing just the amount of space required as an argument a prvalue of type std::size_t.
• If the search finds no declarations, a search is performed in the global scope. Overload resolution is performed on a function call created by passing the amount of space required as a prvalue of type std::size_t.

[Accepted at the July, 2022 meeting.]

Consider:

  struct Allocator;

  struct resumable::promise_type {
    void* operator new(std::size_t sz, Allocator&);
    // ...
  };
  resumable foo() {
    co_return;
  }

Subclause 9.5.4 [dcl.fct.def.coroutine] paragraph 9 specifies:

... The allocation function's name is looked up by searching for it in the scope of the promise type.

• If any declarations are found, overload resolution is performed on a function call created by assembling an argument list. The first argument is the amount of space requested, and has type std::size_t. The lvalues p1 . . . pn are the succeeding arguments.
• Otherwise, a search is performed in the global scope.

If no viable function is found (12.2.3 [over.match.viable]), overload resolution is performed again on a function call created by passing just the amount of space required as an argument of type std::size_t.

Is the example ill-formed because resumable::promise_type is not viable, or is the example well-formed because the global operator new can be used? There is implementation divergence.

See also LLVM issue 54881.