Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123448
Date: Tue, 28 May 2024 15:26:16 +0100 (BST)
To: Ilija Tovilo <tovilo.ilija@gmail.com>
cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Transform exit() from a language construct into
 a standard function
In-Reply-To: <CAPyj-LBpmYv30JFW3x-ZL=28vivrh7d04L97rbXeYxDJirwKCg@mail.gmail.com>
Message-ID: <ca1189e2-4bb7-3008-4b52-694cd14aed8d@php.net>
References: <GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe> <b2IQjZQlOsMoMuk9Jw5edeVfHqqbcWCQc6DQF5jKrRkGryVyvu6rC9sbSW2D-HK9jH2QUmkoIy--aQROFsx-3QPr8CjIfltTnhbZYGxsixI=@gpb.moe>
 <CAPyj-LBpmYv30JFW3x-ZL=28vivrh7d04L97rbXeYxDJirwKCg@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-25938924-1716906376=:61845"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-25938924-1716906376=:61845
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Mon, 27 May 2024, Ilija Tovilo wrote:

> On Sun, May 26, 2024 at 11:47=E2=80=AFPM Gina P. Banyard <internals@gpb.m=
oe>=20
> wrote:
> >
> > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard=20
> > <internals@gpb.moe> wrote:
> >
> > > I would like to formally propose my idea for exit() as a function=20
> > > brought up to the list on 2024-02-24 [1] with the following RFC:=20
> > > https://wiki.php.net/rfc/exit-as-function
> >
> > As there haven't been any comments for nearly two weeks, I'm=20
> > planning on opening the vote for the RFC on Tuesday.

Right now, I am not going to be in favour of this. Specfically because=20
the Backward Incompatible Changes don't list some of the backward=20
breaking changes, and no mitigations are provided. See below.

I also don't see the benefit from doing this in the first place.=20
exit/die has always meant "bail straight out", without any function=20
semantics (from https://www.php.net/exit):

=09exit =E2=80=94 Output a message and terminate the current script

=09exit is a language construct and it can be called without=20
=09parentheses if no status is passed.

It's not that this a particularly new or novel behaviour.

I saw somewhere else in the thread that the exit construct could already=20
throw a catchable exception. I consider that a bug.

> As mentioned early on in private, I don't see a convincing reason to=20
> remove tokenizer/parser support for exit/die. I'd rather see this=20
> handled in the parser directly, by converting the standalone keywords=20
> to function calls. This avoids any backwards incompatibility, and=20
> avoids special handling in zend_compile_const.
>=20
> Another thing that's probably not too important: The PR likely breaks=20
> dead code elimination for exit() and die().

I have just checked this for Xdebug, and you're definitely right with=20
that. With the removal of the ZEND_EXIT opcode, it can not now detect a=20
scope/function exit now.

It also breaks my "do tasks on ZEND_EXIT" with the profiler. It is used=20
to always write the closing profiling footer to the files. Without me=20
being able to overload thati opcode, data would not be complete.
I even have two bugs (with tests) for this:

- https://bugs.xdebug.org/68
- https://bugs.xdebug.org/631=20

Xdebug has been overloading ZEND_EXIT for nearly 20 years now.

> This could be re-added by checking for the never return type instead.

I can't quite see a way on how to do that? The EXIT is replaced by an=20
INIT_FCALL/DO_ICALL:

     4     0  E >   EXT_STMT   =20
           1        ECHO        '55'
     5     2        EXT_STMT   =20
-          3      > EXIT       =20
-    6     4*       EXT_STMT   =20
-          5*       ECHO        '675'
-    7     6*       EXT_STMT   =20
-          7*     > RETURN      null
+          3        INIT_FCALL  'exit'
+          4        DO_ICALL   =20
+    6     5        EXT_STMT   =20
+          6        ECHO        '675'
+    7     7        EXT_STMT   =20
+          8      > RETURN      null

The opcodes don't have direct access to the type mask structure as far=20
as I know.

cheers,
Derick
--8323329-25938924-1716906376=:61845--