GeezerVison

Would it make sense to update zend_undefined_function_helper (etc) to indicate that it is creating a closure from an undefined function (etc) rather than calling the function at the time the error is thrown?
(e.g. check if the next opcode is creating a closure - ZEND_CALLABLE_CONVERT,)

The current implementation:

ZEND_VM_COLD_HELPER(zend_undefined_function_helper, ANY, ANY)
{
	USE_OPLINE
	zval *function_name;

	SAVE_OPLINE();
	function_name = RT_CONSTANT(opline, opline->op2);
	zend_throw_error(NULL, "Call to undefined function %s()", Z_STRVAL_P(function_name));
	HANDLE_EXCEPTION();
}

php > $x = ('missing')(...);

Warning: Uncaught Error: Call to undefined function missing() in php shell code:1
Stack trace:
#0 {main}
  thrown in php shell code on line 1
php > $x = Closure::fromCallable('missing');

Warning: Uncaught TypeError: Failed to create closure from callable: function "missing" not found or invalid function name in php shell code:1
Stack trace:
#0 php shell code(1): Closure::fromCallable('missing')
#1 {main}
  thrown in php shell code on line 1

@TysonAndre Having a more specific error message would be nice, but it wouldn't be as simple as changing that one place. For example, the error for calling an inaccessible method is generated in the get_method object handler, and I don't think we want to thread information about what kind of "call" it is through there.

Possibly we could make the message more generic so it would work in both situations, for example:

Old: Call to undefined function foobar()
New: Reference to undefined function foobar()

Old: Call to private method Foo::bar() from Baz
New: Reference to private method Foo::bar() from Baz

Though maybe that makes the message in the common case slightly harder to understand.

Please improve also dump of Closure to contain the specific method/function name. https://3v4l.org/SjSnR

I added some more test coverage. Anything still missing?