Skip to content

Compatibility

PHP language coverage

cl-cc-php targets modern PHP, including 8.4 and 8.5 language features. Areas with explicit support and test coverage:

  • Classes, interfaces, traits, and enums
  • Attributes (#[...])
  • Property hooks and asymmetric visibility (8.4)
  • Intersection and union types
  • Match expressions, arrow functions, first-class callable syntax
  • Generators (yield, yield from) and Fibers
  • Namespaces, use, declare, include
  • References, including reference rewriting in compiled output

Constructs the frontend does not handle are reported by php-check-supported-forms rather than failing later in the pipeline. If you hit a construct that neither compiles nor is reported, that is a bug worth filing.

Host requirements

SBCL. The runtime builtins use SBCL-specific facilities in places — the I/O and filesystem builtins in particular — so other Common Lisp implementations are not currently supported.

Platform support

flake.nix declares exactly two systems:

System Verified by
x86_64-linux CI, on every push and pull request
aarch64-darwin Maintainer nix flake check runs

aarch64-linux and x86_64-darwin are deliberately not declared. They may well work, but nothing verifies them, and declaring an unverified platform is a promise this project cannot keep.

Note that some filesystem builtins are platform-sensitive; is_dir() in particular has needed platform-specific correction.

Stability of the API surface

The three parse entry points — tokenize-php-source, parse-php-source, parse-php-source-to-cst — are the stable surface.

The %php- runtime builtins are a compilation target. They exist so that code generated by cl-cc can call PHP semantics primitives, and they are exported only because generated code must be able to name them. They change alongside the compiler, and they are not covered by the stability expectations that apply to the parse entry points. Do not build against them directly unless you are working on cl-cc itself.

Relationship to cl-cc

This is the tightest compatibility constraint in the project.

cl-cc-php consumes cl-cc-ast, cl-cc-bootstrap, cl-cc-parse, and cl-cc-vm from a checkout of the cl-cc monorepo rather than from tagged sibling repositories, because those systems have not been split out and are not planned to be. flake.nix consequently takes cl-cc as an unpinned flake = false input, with the exact revision recorded in flake.lock.

The practical consequence: a cl-cc revision and a cl-cc-php revision are only known to work together if flake.lock says so. Bumping the cl-cc input is a change that needs its own test run. The existing v0.1.0 tag on cl-cc predates the packages/ layout this repository expects, so it is not a usable pin.

The other inputs — cl-weave, cl-prolog, cl-parser-kit, cl-json-kit — are pinned to release tags and behave normally. Unlike the first three, which are test-only, cl-json-kit is a real dependency of the shipped cl-cc-php system (json_validate calls into it directly) — see cl-cc-php.asd's :depends-on.