Перейти к содержимому

Дополнительно

Просмотреть как Markdown Редактировать на GitHub Документация по 5b53f69

Внутреннее устройство. Если вы встраиваете Phasis, этот раздел можно пропустить. Если вы меняете движок, каждая страница здесь важна для работы.

Страницы

  • Архитектура — как исходный код превращается в исполняемый: лексер → парсер → AST → компиляция в байткод → виртуальная машина байткода с обходом дерева в качестве резервного варианта. Загрузчик модулей, окружения и роль Phasis\Engine как границы окружения.
  • Виртуальная машина байткода — набор опкодов, цикл диспетчеризации, встроенные кэши, быстрый путь транспилятора исходного кода JsToPhp, эвристика canSkipEnvAlloc для формы функции, а также случаи, когда вызовы обрабатываются через байткод, а когда — обходом дерева.
  • Тесты производительности — текущие показатели bench/, как их интерпретировать, почему ~100× V8 — это предел установившейся производительности обхода дерева и что поможет сократить разрыв.
  • Тестирование — модель эталонов. Каждое изменение проверяется по трём независимым эталонам: Node.js (V8 — достоверный источник сведений о спецификации), test262 и набору проверок побайтного равенства для популярных библиотек.

Правила участия в разработке

  • Не меняйте ядро движка без веской причины. Всё в src/Runtime/, src/Bytecode/, src/Lexer/, src/Parser/ и src/Regex/ находится на критическом пути test262. Изменения без соответствующей проверки test262 чреваты регрессиями. Встроенные функции (src/BuiltIn/) безопаснее, поскольку отдельные тестовые наборы test262 для каждой из них локально выявляют ошибки.
  • Используйте трейты для организации кода, а не классы. Когда файл превышает примерно 2K строк, разделите его на файлы трейтов в соседнем каталоге (src/BuiltIn/Temporal/, src/Runtime/Parts/ и т. д.), вместо создания новых классов. Так сохраняются работающие запросы self:: и не нарушается поверхность API приватных методов.
  • Перед отправкой изменений локально запускайте bin/verify-all. Он запускает PHPStan, PHPCS, все наборы PHPUnit (unit, oracle, popular, wpt) и регрессионную проверку оракула. CI запускает наборы WPT и popular при изменениях в src/; полная матрица test262 запускается вручную, поэтому локально проверяйте затронутые категории test262.
  • Для каждого добавления Web API добавляйте тестовый пример WPT. Поместите .any.js из tests/Wpt/upstream/<area>/ в tests/Wpt/fixtures/<category>/ — и исполнитель тестов подхватит его.

См. также