Zend: move class autoloading from SPL to Zend

[Girgias]

The primary motivation for this change is that this sort of functionality should reside in core and not in an extension.
The reason being is that this causes issues in regard to extension dependencies and resolution, something that prevents GH-14544.

Moreover, we might want to extend the autoloading functionality (by allowing other symbols to be autoloader or registering a class map).

[Girgias]

@petk would doing just this allow #14544 to be merged?

[petk]

This would make the session extension not depend on the spl, yes (meaning the https://bugs.php.net/53141 would be resolved). But the main issue there would still be present - that loop of the registered extensions isn't done optimal yet and it has issues with cyclic dependencies (extension A depends on B, and extension B depends on A).

[Girgias]

This would make the session extension not depend on the spl, yes (meaning the https://bugs.php.net/53141 would be resolved). But the main issue there would still be present - that loop of the registered extensions isn't done optimal yet and it has issues with cyclic dependencies (extension A depends on B, and extension B depends on A).

Are there any other case of cyclic dependencies? Because if not and if we can detect them and error during build/compilation, that would be a more sensible approach IMHO. As cyclic dependencies just cause a lot of pain.

[petk]

Are there any other case of cyclic dependencies? Because if not and if we can detect them and error during build/compilation, that would be a more sensible approach IMHO. As cyclic dependencies just cause a lot of pain.

Yes. Probably there are. That loop would need to be refactored somehow. Because there might be cases like this:

• extension=exif must be after mbstring in php.ini (Windows) #20600

And I can't be sure here. When looping through a list of all enabled extensions (that is retrieved from the main/internal_functions.c and main/internal_functions_cli.c with additional ones defined from the ini directives like extension and zend_extension) there are two points what something happens:

• first the extensions get registered somewhere
• and then after that extensions get loaded.

And that first part is probably needed for cases as described in above linked issue (or in that session and spl hidden dependency). I can't explain this properly as I would need to go through the code in more details to better understand this issue and use proper terminology here.

Basically, what the code should ideally do is:

• get all enabled extensions
• sort the enabled extensions based on their dependencies defined via ZEND_MOD_REQUIRED, ZEND_MOD_OPTIONAL and ZEND_MOD_CONFLICTS.
• and then loop over extensions, register them and load them.
• additionally, the loop should be "smart enough" to deal with possible cyclic dependencies - either if extensions were configured incorrectly or something like that.

For example, another issue here is this: #14067

But I totally understand that doing this is difficult. So whatever you can do here, all good and I agree.

[arnaud-lb]

Suggested change

	ZEND_API void zend_autoload_fcc_map_to_callable_zval_map(zval *return_value) {
	ZEND_API zend_array *zend_class_autoload_functions_as_callables(void) {

[Girgias]

If I do this I seem to be hitting a GC issue if I return (zend_array*)&zend_empty_array; and then on the call site just do RETURN_ARR(zend_autoload_fcc_map_to_callable_zval_map());.

Do I need to do something special?

[arnaud-lb]

Oh I see, that's because zend_empty_array is not collectable so the zval must be marked as such. ZVAL_EMPTY_ARRAY() takes care of that, but it can not be achieved cleanly with the signature I was suggesting.

So I withdraw the signature change from my suggestion:

ZEND_API void zend_class_autoload_functions_as_callables(zval *return_value) {

[Girgias]

Will revert then and add a comment explain why we do this :)

[arnaud-lb]

Looks good to me otherwise (if the zend_autoload_fcc_map_to_callable_zval_map() change I suggested earlier is reverted)