Skip to content

Improve BC support of arginfo files generated by gen_stub.php #13705

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 18, 2024

Conversation

kocsismate
Copy link
Member

@kocsismate kocsismate commented Mar 13, 2024

  • Declared compatibility expectations of stub files are now enforced by a ZEND_STATIC_ASSERT calll at the top of arginfo files. This is hopefully useful for 3rd party extensions so that they don't accidentally include an arginfo file in a PHP version which it doesn't unsupport.
  • Property registration for PHP 7 is fixed: function zend_declare_property_ex() is used again instead of zend_declare_typed_property(). This has been a regression since I added support for exposing doc comments.
  • As a defensive measure, deep cloning is performed before newer features (type declarations, attributes etc.) are discarded before generating legacy arginfo files. Until now, some of the objects were forgotten to be taken care of. These omissions may have resulted in some weird bugs in theory (but probably they didn't have much impact in practice).
  • PHP version related conditions inside non-legacy arginfo files used to possibly check for the 70000 version iD until now if compatibility with PHP 7.0 was declared in a stub. This was not 100% correct, since non-legacy arginfo files are only for PHP 8.0+. Now, I made sure that at least PHP version ID 80000 is used in the preprocessor conditions. The solution was a bit tricky though...

- Declared compatibility expectations of stub files are now enforced by a ZEND_STATIC_ASSERT calll at the top of arginfo files
- Property registration for PHP 7 is fixed: function zend_declare_property_ex() is used again instead of zend_declare_typed_property(). This has been a regression since I added support for exposing doc comments.
- As a defensive measure, deep cloning is performed before newer features (type declarations, attributes etc.) are discarded before generating legacy arginfo files. Until now, some of the objects were forgotten to be taken care of. These omissions may have resulted in some weird bugs in theory (but probably they didn't have much impact in practice).
- PHP version related conditions inside *non-legacy arginfo files* used to possibly check for the 70000 version iD until now if compatibility with PHP 7.0 was declared in a stub. This was not 100% correct, since non-legacy arginfo files are only for PHP 8.0+. Now, I made sure that at least PHP version ID 80000 is used in the preprocessor conditions. The solution was a bit tricky though...
@kocsismate kocsismate changed the title Improve BC support of arginfo files fenerated by gen_stub.php Improve BC support of arginfo files generated by gen_stub.php Mar 13, 2024
@@ -1,6 +1,9 @@
/* This is a generated file, edit the .stub.php file instead.
* Stub hash: dd3f852ea9f8e3a356ed226380edf5cc336f8a4e */

ZEND_STATIC_ASSERT(PHP_VERSION_ID >= 80000, "test_arginfo.h only supports PHP version ID 80000 or newer, "
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you fine with added such static asserts for arginfo files when the stub file has a version constraint?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have any strong opinions about this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, then I merge it, and in case anyone complains, I get rid of it or change it.

@kocsismate kocsismate merged commit 5992a29 into php:master Mar 18, 2024
@kocsismate kocsismate deleted the stub-bc-fixes branch March 18, 2024 21:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants