gen_stub.php: consider dropping support for older PHP ABIs

[DanielEScherzer]

Description

#8931 updated the script so that it could generate arg_info for older versions of the PHP ABI. At the time, it supported 7.0, 8.0, 8.1, and 8.2.

Given that PHP 8.0 has reached EOL, I propose that we drop support for 7.0 or both 7.0 and 8.0, which would allow simplifying the generator script

[DanielEScherzer]

CC @kocsismate - happy to work on this if the patches would be approved

[bwoebi]

In my opinion the arginfo generation for old versions of the PHP API is misguided and is better covered by a compatibility shim translating the header invocations to something compatible with old versions.

I'd drop it altogether and rather maintain something like:
https://github.com/DataDog/dd-trace-php/blob/9d041954f90ff77b23f73c0108336279fbf04eb9/ext/compatibility.h#L232-L244 (these highlighted lines are just the compatibility shims for PHP 7, there's more in that file for other versions.)

[cmb69]

Note that gen_stub.php is not only used for php-src, but also by some extensions. These may very well still target older PHP releases. I was told only 2 weeks ago by an extension maintainer that they still deliberately support PHP 5.6.

Maybe @remicollet has something to say about this.

[Girgias]

Yes, gen_stub.php is very much used by extensions as it is provided by the skeleton. And I think that is a good think, but I also think @bwoebi's solution of having a compatibility header is probably a better idea as I wouldn't be surprised of extensions already having such a header (or defines).

[kocsismate]

I wouldn't be surprised of extensions already having such a header (or defines).

Yes, definitely! I surely saw a few such headers for XDebug a few years ago, but I guess other stub users also have to create their own shims as gen_stub.php doesn't always generate 100% compatible code below PHP 8.0.

Regarding the original question: I know the possible BC compliance makes gen_stub.php very convoluted and difficult to maintain, and i'm happy to find a possibility which improves the situation. However, I don't think it's a good idea to remove support for PHP 7.4 and PHP 8.0 yet.. I would rather prefer if we had some kind of ABI compatibility promise, like maintaining ABI compatibility for e.g. at least two major releases (PHP 7.x: until 9.x, PHP 8.y: until 10.y), or like giving at least 6-8 (?) years of support.

[NattyNarwhal]

FWIW, I'm supporting 7.3+ in the IBM database extensions, but I'm not opposed to having to raise the minimum supported version, or use an alternative to the legacy arginfo. Another thing is the CI there for it also downloads a specific version of gen_stub, so perhaps a legacy gen_stub could be provided that i.e. matches a (set of?) versions?

[nikic]

apcu uses gen_stubs.php all the way back to PHP 7.0 (using @generate-legacy-arginfo).

[DanielEScherzer]

After looking into the code a bit more, even just dropping 7.0 support would dramatically simplify a lot of things. Given that since I originally filed this, 8.2 has ended normal support, and we are talking about what the gen_stub script in 8.5 will support, I don't think its unreasonable to drop just 7.0 support

I wouldn't be surprised of extensions already having such a header (or defines).

Yes, definitely! I surely saw a few such headers for XDebug a few years ago, but I guess other stub users also have to create their own shims as gen_stub.php doesn't always generate 100% compatible code below PHP 8.0.

Regarding the original question: I know the possible BC compliance makes gen_stub.php very convoluted and difficult to maintain, and i'm happy to find a possibility which improves the situation. However, I don't think it's a good idea to remove support for PHP 7.4 and PHP 8.0 yet.. I would rather prefer if we had some kind of ABI compatibility promise, like maintaining ABI compatibility for e.g. at least two major releases (PHP 7.x: until 9.x, PHP 8.y: until 10.y), or like giving at least 6-8 (?) years of support.

Especially if we aren't always compatible below 8.0, we can remove the claim of that support.
Are extensions that still support 7.4 or lower still changing their stubs?

[kocsismate]

PHP 7.4 was released in 2019, so it will be already 6 years in a few months. Since PHP 8.0 was very disruptive to say at least, I guess a lot of people (and extensions) still use and support PHP 7.x. That's why, if you ask me, I would probably still wait a few years with the removal. Of course, the input from actual maintainers of 3rd party extensions would be more useful to have than my assumptions...

TBH nowadays, gen_stub.php doesn't change as often as it used to change (besides your refactorings), so it looks like its maintenance cost is still tolerable even though the huuge complexity of its code.

[TimWolla]

Are extensions that still support 7.4 or lower still changing their stubs?

Yes. I'm maintaining one (closed source) and recently also modernized https://github.com/beberlei/hdrhistogram-php from resources to objects, which supports everything from 7.0 to 8.5 just fine.

[bwoebi]

Yup, I'm maintaining dd-trace-php, which is also compatible from PHP 7.0 upwards.