Re: com php-src: Implement call_user_func() and call_user_func_array() using special opcodes. In some rare cases it leads to insignificant changes in
error messages.: Zend/tests/001.phpt Zend/tests/002.phpt Zend/tests/003.phpt Zend/tests/call_user_func_004.phpt Zend/tests/call_user_func_005.phpt
Zend/tests/fr47160.phpt Zend/tests/objects_027.phpt Zend/zend_compile.c Zend/zend_execute.c Zend/zend_execute_API.c Zend/zend_vm_def.h
Zend/zend_vm_execute.h

On Thu, Jul 24, 2014 at 8:45 PM, Dmitry Stogov <dmitry@zend.com> wrote: > Hi Nikita, > > Thanks for info. > Please record this as a "known problem" at > https://wiki.php.net/phpng > (may be even add a PHPT for phpng). > I don't think it's a real problem, but we will need to analyze all the > incompatibilities and make decision about each of them - if it's a bug or > unexplained behavior of PHP5. > > Now I remember your patch that changed FOREACH behavior. I liked the > idea, just didn't like to break behavior in inphpng, but once we merge > phpng into master I think we should make this break. RFC, voting, etc... we > mus not explain users that PHP behavior depends on the values of > reference-counters :) > > Thanks. Dmitry. > I think it would be good to resolve the test issues as soon as possible (and before merging to master) - right now the situation is a bit annoying because one has to filter out phpng-failures from the ones that your change introduced. I would suggest to a) Update tests where there is an intended behavior change (i.e. regarding duplicate parameters and func_get_arg) b) Update tests where the old behavior is obviously a bug (e.g. Zend/tests/bug60825.phpt) c) Mark everything where the correct behavior is unclear or fixing it is hard (e.g. the foreach failures) as XFAIL, with a special label (PHPNG) in the xfail text, so we know that these still need to be resolved, but they don't get in the way of other development. Thanks, Nikita