Infer static for closures

[iluuu1994]

See #19754 (comment)

[iluuu1994]

@dktapps Ping. I haven't done any benchmarking yet.

[dktapps]

This isn't caching static closures yet, right? So there should be no observable effect on performance

[iluuu1994]

This isn't caching static closures yet, right?

Right. IIRC static closures themselves have a small benefit, though I didn't see it in the CI benchmark. I'm not sure if maybe Symfony already uses linting to add static.

[iluuu1994]

Okay, testing Symfony Demo with all static closures turned into non-static ones shows virtually no improvement. Regardless, they should benefit if we can cache them. I'll try this in the same PR then, given this one isn't useful on its own.

[arnaud-lb]

One drawback of non-static closures is that they retain $this, which can increase memory usage when the lifetime of $this is supposed to be shorter and references a large graph. I believe this is why coding guidelines and IDEs recommend to manually declare closure as static.

Big +1 on this.

[arnaud-lb]

This could be a zend_closure flag, passed to zend_create_closure() by ZEND_DECLARE_LAMBDA_FUNCTION. The flag can be stored in OBJ_EXTRA_FLAGS() as there is no other place to store a flag in zend_closure. I do this in the pfa branch: https://github.com/arnaud-lb/php-src/blob/23dce325280c7c6c90043ad3bf830073f6838df3/Zend/zend_types.h#L873 + https://github.com/arnaud-lb/php-src/blob/23dce325280c7c6c90043ad3bf830073f6838df3/Zend/zend_closures.c#L31

[iluuu1994]

Quick test: In Symfony Demo with all static closures turned into non-static ones, this patch can turn 122/283 into static ones. That's ~43%, so not bad at all. How many of those can also be cached remains to be seen.

[dktapps]

Some other weird cases that might need to be considered:

• Variable variables
• include,require et al
• eval()

Source: https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blame/b0a17bf1288a696cba2c8492126f0a485d5637f0/src/Fixer/FunctionNotation/StaticLambdaFixer.php#L110

[dktapps]

To be honest I start to wonder if this actually makes sense considering the number of obscure conditions that might cause an unintended $this binding just for a potential usage. It'd avoid some unnecessary refs but there'd still be plenty of cases where static would be needed to avoid cycles and accidental refs. (I suppose it'd still benefit for common array_map() style cases where a throwaway closure is used, but 🤷 )

Has there been any discussion about a shorter syntax for static closures? e.g. something like sfn() (idk)

[iluuu1994]

Var var is already handled in this patch. I forgot about eval, but that's quite rare as well, especially in closures.