Hi reeze, The original "return type" patch was designed to support internal functions as well. So I think, this is just a good addition.
Only one note: I'm not sure, if we need the addition check in ZEND_DO_FCALL handler. On one hand it verifies that internal function returns proper result (but they MUST do it). On the other hand, it also slowdowns each additional call. Instead of modifying zend_verify_return_type() I would add zend_verify_internal_return_type(), and use: ZEND_ASSERT((fbc->common.fn_flags & ZEND_ACC_HAS_RETURN_TYPE) && zend_verify_internal_return_type(fbc, EX_VAR(opline->result.var))); This would allow catching error in DEBUG build, but won't slowdown RELEASE build. If you agree, I may just commit this. Thanks. Dmitry. On Thu, Feb 5, 2015 at 7:01 AM, reeze <re...@php.net> wrote: > PS: > > There is no enough unit tests to cover all of the branches, if we want then > I have to add a bunch of for testing functions and classes in ZEND_DEBUG, > what is the better way? > > On 5 February 2015 at 11:54, reeze <re...@php.net> wrote: > > > Hi all, > > > > RFC: https://wiki.php.net/rfc/internal_function_return_types > > > > I noticed that return types RFC[1] didn't support internal functions, I > > just open a PR[2] to support it. > > > > There are some open issues we can discuss: > > > > 1. User land return types didn't stop the php, the current implementation > > raise error to stop PHP from start, this may help debug problem. > > 2. User land return types didn't support Nullable types, but the RFC > > return types internally support it, I think it is feature. is that > > acceptable? > > > > Thank you. > > > > --- > > > > [1] https://wiki.php.net/rfc/return_types > > [2] https://github.com/php/php-src/pull/1050 > > >
