متقدم
الأجزاء الداخلية. إذا كنت تدمج Phasis في تطبيقك، يمكنك تخطي هذا القسم. أما إذا كنت تعدّل المحرك، فكل صفحة هنا أساسية.
الصفحات
- البنية — كيف يتحول المصدر إلى تنفيذ: lexer → parser → 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 المتأثرة. - أضف نموذج WPT لكل إضافة إلى Web API. ضع
.any.jsمنtests/Wpt/upstream/<area>/داخلtests/Wpt/fixtures/<category>/وسيلتقطه المشغّل تلقائيًا.