Перейти до вмісту

Розширене

Переглянути як Markdown Редагувати на GitHub Документація для 5b53f69

Внутрішня будова. Якщо ви вбудовуєте Phasis, цей розділ можна пропустити. Якщо ви змінюєте рушій, кожна сторінка тут критично важлива.

Сторінки

  • Архітектура — як вихідний код перетворюється на виконання: лексичний аналізатор → парсер → AST → компіляція в байт-код → байт-кодова VM із резервним обходом дерева. Завантажувач модулів, середовища виконання та роль Phasis\Engine як межі середовища.
  • Байт-кодова VM — набір опкодів, цикл диспетчеризації, вбудовані кеші, швидкий шлях транспілятора 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>/, і виконавець підхопить його.

Див. також