Hi Adrian, > On 28 Nov 2022, at 20:44, Iain Sandoe <i...@sandoe.co.uk> wrote:
>> Bootstrapping and running the testsuite on x86_64 was successfull. No >> regression occured. > > This looks resonable to me, as said in the PR. I’d like to test a little > wider with some larger > codebases, if you could bear with me for a few days. So wider testing (in this case folly) reveals that, although the analysis seems reasonable, this is not quite the right patch to fix the issue. It can be that CONSTRUCTORS contain nested await expressions, so we cannot simply punt on seeing one. My hunch is that the real solution lies in (correctly) deciding whether to promote the temporary or not. Jason recently made a change that identifies whether a target expression is expected to be elided (i.e. it is a direct intializer for another object) - I think this might help in this case. My concern is whether I should read “expected to be elided” to be a guarantee (“expected” to me could also be read “but it might not be”). As is, the patch is not OK since it regresses cases with nested await expressions in CONSTRUCTORS. sorry for not spotting that sooner, Iain
