> On 15 Sep 2021, at 20:50, Jason Merrill <jason@redhat.com> wrote:
> On 9/15/21 14:32, Iain Sandoe wrote:
>> Hi Jason,
>>> On 15 Sep 2021, at 18:32, Jason Merrill <jason@redhat.com> 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: