php_executor is the transport-independent compile/execute owner for normal
PHP program execution. It is used by the VM CLI compatibility path and by the
integrated HTTP server.
crates/php_executor/src/pipeline.rsowns source analysis, semantic frontend invocation, IR lowering, IR verification, and optimizer application.crates/php_executor/src/executor.rsowns the publicPhpExecutor,CompiledPhpScript, compile, execute, and compile-then-execute entrypoints.crates/php_executor/src/request.rsowns per-request include-loader and filesystem capability setup.crates/php_executor/src/diagnostics.rsowns PHP-shaped diagnostic rendering for executor-backed compile and VM failures.crates/php_executor/src/cache.rsowns the process-local compiled-script cache consumed by the server.crates/php_executor/src/engine_compat.rskeeps the legacyEngineInput/execute_phppath stable for compatibility binaries.
The executor does not own HTTP transport, routing, static files, CLI argument parsing, disk bytecode artifact caching, or report/debug commands that inspect frontend or VM internals.
php_server supplies HTTP request metadata and response mapping, then calls the
executor. php_vm_cli owns user-facing command behavior and delegates normal
execution orchestration to the executor where practical. Debug commands such as
IR dumps, bytecode reports, JIT inspection, or persistent-feedback tools may
continue to call lower layers directly because their output is intentionally
internal.
Public executor inputs and outputs are owned Rust data structures. Transport
layers should not mutate raw VmOptions after execution starts. New execution
features should be added as typed executor options first when both server and
CLI paths need the behavior.
PHP-visible stdout, stderr text, exit status, diagnostics, request side effects, and fixture behavior must stay stable when orchestration moves into the executor. Any remaining duplicate path must document why it needs direct access to lower-level metadata.