> On 15 Sep 2021, at 20:50, Jason Merrill <[email protected]> wrote: > On 9/15/21 14:32, Iain Sandoe wrote: >> Hi Jason, >>> On 15 Sep 2021, at 18:32, Jason Merrill <[email protected]> wrote: >>> >>> On 9/14/21 11:36, Iain Sandoe wrote: >>>> Hi >>>> Some small code cleanups that allow us to have just one place that >>>> we handle a statement with await expression(s) embedded. Also we >>>> can reduce the work done to figure out whether a statement contains >>>> any such expressions. >>>> tested on x86_64,powerpc64le-linux x86_64-darwin
>>> What's the rationale for this assert? [expr.await] seems to say explicitly
>>> that an await can appear in the initializer of an init-statement.
>> Indeed (and we would not expect otherwise)
>> - but currently GCC appears to generate code for:
>> for (loop_ind_var = init; … ; …) {}
>> that looks like:
>> loop_ind_var = init;
>> for (; … ; …) {}
>> If that changes (and the init contains an await expr) then we’d need to
>> apply that transform manually, so the assert is in place to check that the
>> assumption about existing behaviour is met.
>
> Then the patch is OK with that rationale in a comment.
thanks.
this is what was pushed:
0001-coroutines-Small-cleanups-to-await_statement_walker-.patch
Description: Binary data
