https://github.com/php/php-src/pull/1004
Wondering if anyone has an objection to me merging this. It just
offers extensions a chance to alter the AST prior to bytecode
emission. Mostly for evil things, but potentially for 3rd-party
optimizers or whatevs. Does it need an RFC? The very minor
indirection cost hides itself behind OpCache, so it should harm
anything...
-Sara
Morning Sara,
Great idea, +1, also agree that it doesn't really need an RFC ... but
I'm always wrong ...
Cheers
Joe
https://github.com/php/php-src/pull/1004
Wondering if anyone has an objection to me merging this. It just
offers extensions a chance to alter the AST prior to bytecode
emission. Mostly for evil things, but potentially for 3rd-party
optimizers or whatevs. Does it need an RFC? The very minor
indirection cost hides itself behind OpCache, so it should harm
anything...-Sara
Hi,
https://github.com/php/php-src/pull/1004
Wondering if anyone has an objection to me merging this. It just
offers extensions a chance to alter the AST prior to bytecode
emission. Mostly for evil things, but potentially for 3rd-party
optimizers or whatevs. Does it need an RFC? The very minor
indirection cost hides itself behind OpCache, so it should harm
anything...
Good idea.
I think it was even planed when AST was introduced. You may check with
Nikita :)
Cheers,
Pierre
https://github.com/php/php-src/pull/1004
Wondering if anyone has an objection to me merging this. It just
offers extensions a chance to alter the AST prior to bytecode
emission. Mostly for evil things, but potentially for 3rd-party
optimizers or whatevs. Does it need an RFC? The very minor
indirection cost hides itself behind OpCache, so it should harm
anything...
Totally okay with making that hookable, but not sure if compile_top_stmt is
the best place to do that, at least in the form implemented in the PR.
Assuming that you want to implement a preprocessing pass on the AST the
fast that zend_compile_top_stmt is called recursively might be somewhat
inconvenient. Maybe compile_top_stmt should at least also call
compile_top_stmt instead of zend_compile_top_stmt?
Nikita
Totally okay with making that hookable, but not sure if compile_top_stmt is
the best place to do that, at least in the form implemented in the PR.
Assuming that you want to implement a preprocessing pass on the AST the fast
that zend_compile_top_stmt is called recursively might be somewhat
inconvenient. Maybe compile_top_stmt should at least also call
compile_top_stmt instead of zend_compile_top_stmt?
I did think about that, and ended up with this spot on the idea that
one could just let the main implementation worry about recursive, and
only alter patters as they're seen.
For example, if my extension wants only wants to do constant folding,
I might wait until I get fed an ast node for looking up constants
rather than drilling down myself, then leaving the engine to drill
down again.
That said, I'm not married to that approach, I could add the hook more
here instead and be just as happy:
diff --git a/Zend/zend_language_scanner.l b/Zend/zend_language_scanner.l
index 2412631..0ebf0c2 100644
--- a/Zend/zend_language_scanner.l
+++ b/Zend/zend_language_scanner.l
@@ -586,6 +586,9 @@ ZEND_API zend_op_array
*compile_file(zend_file_handle file_handle, int type)
if (compiler_result != 0) { / parser error */
zend_bailout();
}
-
if (zend_ast_hook) { -
zend_ast_hook(CG(ast)); -
} zend_compile_top_stmt(CG(ast)); zend_ast_destroy(CG(ast)); zend_arena_destroy(CG(ast_arena));
Hi!
https://github.com/php/php-src/pull/1004
Wondering if anyone has an objection to me merging this. It just
offers extensions a chance to alter the AST prior to bytecode
No objection but I wonder if it's time to have some list of the hooks -
especially in the light of the effort for making ZE API look like an API.
Also, I like "pre-processor hook" a bit better (second patch).
Stas Malyshev
smalyshev@gmail.com