[PFA 2/n] Support PFA functionality #20848

arnaud-lb · 2026-01-06T12:02:28Z

RFC: https://wiki.php.net/rfc/partial_function_application_v2

This follows #20717. This implements most of the RFC, except PFAs in constant expressions, and some optimization.

I wanted to split this PR more, but I didn't find a way to achieve this that makes sense.

A partial application is compiled to the usual sequence of function call
opcodes (INIT_FCALL, SEND_VAR, etc), but the sequence ends with a
CALLABLE_CONVERT_PARTIAL opcode instead of DO_FCALL, similarly to
first class callables. Placeholders are compiled to SEND_PLACEHOLDER opcodes:

$f = f($a, ?)

0001 INIT_FCALL f
0002 SEND_VAR CV($a)
0003 SEND_PLACEHOLDER
0004 CV($f) = CALLABLE_CONVERT_PARTIAL

SEND_PLACEHOLDER sets the argument slot type to _IS_PLACEHOLDER.

CALLABLE_CONVERT_PARTIAL uses the information available on the stack to
create a Closure and return it, consuming the stack frame in the process
like an internal function call.

We create the Closure by generating the relevant AST and compiling it to an
op_array.

The op_array is cached in the Opcache SHM and inline caches. The SHM key is prefixed with pfa:// to avoid any collision with actual files. When Opcache is disabled, we cache PFA op_arrays a global hash table. This is mainly useful for polymorphic PFAs, as the inline cache stores only a single entry.

TimWolla

Looked at 43/143 files with a mix of tests and C code.

Zend/zend_execute.c

TimWolla · 2026-01-07T11:23:04Z

Zend/tests/partial_application/errors_004.phpt

+
+?>
+--EXPECTF--
+Fatal error: Uncaught ArgumentCountError: f(): Argument #2 ($b) not passed in %s:6


Is it possible to improve the error message here to make it clear that this is happening during partial application?

This is not specific to partials: https://3v4l.org/biQNc

TimWolla · 2026-01-07T11:25:06Z

Zend/tests/partial_application/errors_005.phpt

+
+?>
+--EXPECT--
+ArgumentCountError: Closure::__invoke(): Argument #3 ($c) must be passed explicitly, because the default value is not known


As a user the error message reads odd, because stating that the default value is “unknown” implies that it is unclear whether there is one. If this is a technical restriction this should be rephrased to something like “cannot be determined for Closures” or something like that.

This error is not specific to partials or Closures: https://3v4l.org/Kl9M1

It is thrown when a parameter with position n < func_num_args() is not specified, and has a default value of UNKNOWN, like here:

php-src/ext/standard/basic_functions.stub.php

Line 1689 in 643cf62

function array_keys(array $array, mixed $filter_value = UNKNOWN, bool $strict = false): array {}

The reason it can happen is that functions assume that all arguments bellow func_num_args() are specified, but due to named args it's not always the case. So the engine fills the unspecified args bellow func_num_args() with their default value, but that's not possible with UNKNOWN.

Closure::__invoke() is a special case of this, as the default value is always unknown for this function (this affects only calling __invoke() explicitly).

I'm realizing that in the context of PFAs, we could probably avoid this by making placeholders without a default value required. I can look at this in a separate PR after this one.

Zend/tests/partial_application/magic_003.phpt

Zend/tests/partial_application/rfc_examples_incompatible_functions.phpt

Zend/zend_ast.c

TimWolla

74/144

Zend/tests/partial_application/non_dynamic_call_funcs.phpt

TimWolla · 2026-01-08T08:31:08Z

Zend/tests/partial_application/recorded_warnings.phpt

+
+Deprecated: Using "_" as a type name is deprecated since 8.4 in %s on line 5


I think this error message being emitted here is not great, because this is not actionable by the user who have written the PFA call (it can only be fixed by the author of the function being called).

Indeed.

Possible alternative ways to handle these errors:

Prefix errors with "During compilation of partial application:"

Discard non-fatal errors emitted during compilation of PFAs

Implement workarounds to avoid emitting any error

The second one seems to be the most sensible, as the errors are actually related to the function being called.

Zend/tests/partial_application/references_001.phpt

Zend/tests/partial_application/references_002.phpt

Zend/tests/partial_application/rfc_examples_debug.phpt

Zend/tests/partial_application/statics_002.phpt

Zend/tests/partial_application/statics_003.phpt

Zend/tests/partial_application/variation_invoke_001.phpt

Zend/tests/partial_application/variation_ex_001.phpt

TimWolla · 2026-01-08T08:41:12Z

Zend/tests/partial_application/variation_scope_001.phpt

I can't imagine what else than Foo would be returned for get_called_class(). Should this test involve inheritance?

Yes, this is just testing basic functionality. That get_called_class() works as expected is obvious with the current implementation, but may not have been with the previous one where the call was made in a more custom way.

RFC: https://wiki.php.net/rfc/partial_function_application_v2 Co-authored-by: Joe Watkins <[email protected]>

Zend/tests/partial_application/rebinding_001.phpt

Zend/tests/partial_application/variation_call_001.phpt

Zend/zend_compile.c

TimWolla

At 100/146 files now. Looked at a majority (but not yet all of the tests). Only looked at the C files with a "small" number of changes, since I can only mark files as reviewed in a binary fashion and preferred getting as many files collapsed as possible.

TimWolla · 2026-01-15T22:18:05Z

Zend/tests/partial_application/variation_closure_001.phpt

+  @@ %s 6 - 6
+
+  - Bound Variables [2] {
+      Variable #0 [ $fn ]


Should we have a second test (same file is fine) where one of the Closure parameters is called $fn?

TimWolla · 2026-01-15T22:24:00Z

ext/opcache/ZendAccelerator.c

+		 * in this case. */
+		ptr = called_function->op_array.opcodes;
+	} else {
+		ptr = (void*) called_function;


Explicit void casts always look fishy. Is this because of the const? Declare const void *ptr; then.

Suggested change

ptr = (void*) called_function;

ptr = called_function;

TimWolla · 2026-01-15T22:25:00Z

ext/opcache/ZendAccelerator.c

+	return key;
+}
+
+zend_op_array *zend_accel_pfa_cache_get(const zend_op_array *declaring_op_array,


Can / Should this return const zend_op_array *?

TimWolla · 2026-01-15T22:29:10Z

Zend/zend_object_handlers.c

 	func->num_args = 0;
 	func->required_num_args = 0;
-	func->arg_info = (zend_arg_info *) arg_info;
+	func->arg_info = zend_call_trampoline_arginfo;


Is this a pre-existing bug? This should be spun out into a separate PR then.

I stumbled over this part of the diff for a while, since I didn't see where you introduced zend_call_trampoline_arginfo until I realized this is not new.

TimWolla

Did a first pass at zend_partial.c

TimWolla · 2026-01-15T22:34:38Z

Zend/zend_partial.c

+#define IS_STATIC_CLOSURE(function) \
+	(((function)->common.fn_flags & (ZEND_ACC_STATIC|ZEND_ACC_CLOSURE)) == (ZEND_ACC_STATIC|ZEND_ACC_CLOSURE))


This could be a proper (inline) function.

TimWolla · 2026-01-15T22:36:16Z

Zend/zend_partial.c

+	return SUCCESS;
+}
+
+static bool zp_name_exists(zend_string **names, uint32_t num_names, zend_string *name)


Suggested change

static bool zp_name_exists(zend_string **names, uint32_t num_names, zend_string *name)

static bool zp_name_exists(const zend_string **names, uint32_t num_names, const zend_string *name)

Constifying to make Gina happy.

TimWolla · 2026-01-15T22:42:27Z

Zend/zend_partial.c

+		uint32_t n = offset - function->common.num_args;
+		zend_string *orig_name = zp_get_param_name(function, function->common.num_args);
+		zend_string *new_name;
+		do {
+			new_name = zend_strpprintf_unchecked(0, "%S%" PRIu32, orig_name, n);
+			if (!zp_name_exists(names, num_names, new_name)) {
+				break;
+			}
+			n++;
+			zend_string_release(new_name);
+		} while (true);


I stumbled over the "infinite" do-while loop, because that intuitively feels more complicated than a regular while(true). I see why it's done here that way when reading the code.

Here's a suggestion that perhaps makes the intent more clear. Feel free to disregard:

Suggested change

uint32_t n = offset - function->common.num_args;

zend_string *orig_name = zp_get_param_name(function, function->common.num_args);

zend_string *new_name;

do {

new_name = zend_strpprintf_unchecked(0, "%S%" PRIu32, orig_name, n);

if (!zp_name_exists(names, num_names, new_name)) {

break;

}

n++;

zend_string_release(new_name);

} while (true);

zend_string *orig_name = zp_get_param_name(function, function->common.num_args);

zend_string *new_name;

for (uint32_t n = offset - function->common.num_args;; n++) {

new_name = zend_strpprintf_unchecked(0, "%S%" PRIu32, orig_name, n);

if (!zp_name_exists(names, num_names, new_name)) {

break;

}

zend_string_release(new_name);

}

TimWolla · 2026-01-15T22:56:41Z

Zend/zend_partial.c

+	}
+}
+
+static bool zp_is_power_of_two(uint32_t x)


Suggested change

static bool zp_is_power_of_two(uint32_t x)

static inline bool zp_is_power_of_two(uint32_t x)

FWIW: This is in C23 as stdc_has_single_bit_*() and could possibly be polyfilled in zend_portability.h.

TimWolla · 2026-01-15T23:02:47Z

Zend/zend_partial.c

+}
+
+/* Can not use zend_argument_error() as the function is not on the stack */
+static zend_never_inline ZEND_COLD void zp_argument_error(zend_class_entry *error_ce,


This would possibly also be useful for the new TYPE_ASSERT OPcode from my array_map() optimization PR.

TimWolla · 2026-01-15T23:03:37Z

Zend/zend_partial.c

+		} else {
+			ZEND_ASSERT(opline->opcode == ZEND_RECV);
+		}
+	} else if (function->type == ZEND_INTERNAL_FUNCTION) {


Is there a type that is neither USER nor INTERNAL? Otherwise this should just be an else (or possibly an else with an unreachable).

TimWolla · 2026-01-15T23:06:10Z

Zend/zend_partial.c

+						default_value_ast, attributes_ast, NULL, NULL);
+
+			} else if (!Z_ISUNDEF(argv[offset])) {
+				// TODO: If the pre-bound parameter is a literal, it can be a


github-actions bot added Category: Build System Category: Engine Extension: opcache Category: Optimizer ABI break labels Jan 6, 2026

TimWolla added the RFC label Jan 6, 2026

TimWolla reviewed Jan 7, 2026

View reviewed changes

arnaud-lb mentioned this pull request Jan 7, 2026

Introduce zend_ast_call_get_args() #20859

Merged

TimWolla reviewed Jan 8, 2026

View reviewed changes

arnaud-lb and others added 15 commits January 8, 2026 12:30

Partial application

5efd54c

RFC: https://wiki.php.net/rfc/partial_function_application_v2 Co-authored-by: Joe Watkins <[email protected]>

Remove unnecessary change

0849041

Skip preload test on Windows

d14ca74

Comments

1617a73

Improve type coherency

98e64d5

Clarify

6819628

Useless memset

0326e5d

Move include

5399547

Rename tests

ccca2eb

Fix test

cbcdbc1

Better type

96c4a78

Generated file

ec25cd6

Consistency

029481c

Fix test name

3fc7f7f

Improve tests

2cf2ae1

arnaud-lb force-pushed the partials-v2-gen branch from 0b7a4a5 to 2cf2ae1 Compare January 8, 2026 11:32

arnaud-lb marked this pull request as ready for review January 13, 2026 15:13

arnaud-lb requested a review from dstogov as a code owner January 13, 2026 15:13

TimWolla reviewed Jan 15, 2026

View reviewed changes

arnaud-lb mentioned this pull request Jan 15, 2026

zend_compile: Optimize array_map() with callable convert callback into foreach #20934

Open

Improve tests

87cbfc4

arnaud-lb added 2 commits January 15, 2026 16:53

Improve tests

96310e7

Update comment, add tests

f1d1263

TimWolla reviewed Jan 15, 2026

View reviewed changes


		Deprecated: Using "_" as a type name is deprecated since 8.4 in %s on line 5

		#define IS_STATIC_CLOSURE(function) \
		(((function)->common.fn_flags & (ZEND_ACC_STATIC\|ZEND_ACC_CLOSURE)) == (ZEND_ACC_STATIC\|ZEND_ACC_CLOSURE))

	static bool zp_name_exists(zend_string *names, uint32_t num_names, zend_string name)
	static bool zp_name_exists(const zend_string *names, uint32_t num_names, const zend_string name)

	static bool zp_is_power_of_two(uint32_t x)
	static inline bool zp_is_power_of_two(uint32_t x)

[PFA 2/n] Support PFA functionality #20848

Are you sure you want to change the base?

[PFA 2/n] Support PFA functionality #20848

Conversation

arnaud-lb commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arnaud-lb Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

arnaud-lb commented Jan 6, 2026 •

edited

Loading

arnaud-lb Jan 8, 2026 •

edited

Loading