Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122257
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-119-ga8b98d1bd8-fm-20240108.001-ga8b98d1b
MIME-Version: 1.0
Message-ID: <1a292ec3-3033-4579-bc36-5aba35600c8f@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LAFJ48bVe-myrZT8svYbpye8uN4Wj-sxdsd_wQcpk33Bw@mail.gmail.com>
References: 
 <CAPzBOBMh5DR9opccsXHaijBFYG7gk=gAOBpnHFRVHKh6+Mzh8A@mail.gmail.com>
 <CAPyj-LAFJ48bVe-myrZT8svYbpye8uN4Wj-sxdsd_wQcpk33Bw@mail.gmail.com>
Date: Thu, 25 Jan 2024 17:37:10 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Discussion: making continue and break into an expression
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jan 25, 2024, at 11:28 AM, Ilija Tovilo wrote:


> This leads to very similar issues as break/continue inside blocks. See:
> https://wiki.php.net/rfc/match_blocks#technical_implications_of_control_statements
>
> I'll try to explain.
>
> The VM works with temporary variables. For the expression foo() +
> bar() two temporary variables for the result of foo() and bar() will
> be created, which are then used for the + operation. Normally, + will
> consume both operands, i.e. use and then free them. However, with
> break/continue etc. being expressions, it would become possible to
> skip over the consuming instructions.
>
>     do {
>         echo foo() + break;
>     } while (true);
>     echo 'Done';
>
> Pseudo opcodes:
>
>     0000 V1 = CALL foo
>     0001 JMP 0005
>     0002 V2 = ADD V1 false ; false is here represents a bottom value
> that will never actually be used
>     0003 ECHO V2
>     0004 JMP 0000
>     0005 ECHO 'Done'
>
> Since JMP will skip over the ADD instruction, V1 remains unused. A
> similar problem already exists for break/continue in foreach itself.
>
>     foreach ($foos as $foo) {
>        foreach ($bars as $bar) {
>            break 2;
>        }
>     }
>
> foreach holds a copy of $bars (in case it gets modified) that normally
> gets cleaned up when the loop ends. With break over multiple
> loop-boundaries, we can completely skip over this freeing mechanism.
> PHP solves this by inserting an explicit FE_FREE instruction before
> the break 2, which itself is essentially just a JMP to the end of the
> outer loop.
>
> Hopefully it's now more evident why this is a problem:
>
>     while (true) {
>        foo() && break;
>     }
>
> foo() returns a value that would normally be consumed by the &&
> operation. However, with break, we may skip over the && operation
> entirely. As such, the break itself becomes responsible for freeing
> these values. This requires significant changes in the compiler to
> track variables that are currently "live" (i.e. haven't been consumed
> yet), and emitting FREE opcodes for them as needed. I've implemented
> this for match blocks here:
>
> https://github.com/php/php-src/compare/master...iluuu1994:php-src:match-blocks-var-tracking
>
> However, note that due to complexity, I've decided to disallow using
> break/continue and the likes in such contexts to avoid this issue
> completely, which isn't possible for what you are suggesting.
>
> There's another related issue.
>
>     foo(bar(), break);
>
> Function calls in PHP consist of multiple instructions, namely an
> INIT_CALL, 0-n SEND and a DO_CALL opcode. INIT_CALL creates a stack
> frame, SEND pushes arguments onto the stack frame, and DO_CALL starts
> the execution of the function and frees both arguments and stack frame
> when the function ends. If prior to a SEND opcode we break, we skip
> over the DO_CALL, so the stack frame needs to be freed manually.
>
> The patch linked above solves this by inserting CLEAN_UNFINISHED_CALLS
> opcodes that do as the name suggests. This mechanism is already used
> for exceptions. This should work for you, but was insufficient for
> match blocks, for reasons I won't get into here.
>
> All this to say: Don't expect the implementation here to be trivial.
>
> Regards,
> Ilija


I'm curious, how did `throw` expressions manage to avoid these issues?  Or was it just "Ilija did the hard work of tracking down the weirdness?"

--Larry Garfield