Ctags: PHP heredoc (<<

jespinal ، هل تتحدث عن هذا التغيير: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes ؟

$ git diff |cat
git diff |cat
diff --git a/parsers/php.c b/parsers/php.c
index e3fdc241..ace25561 100644
--- a/parsers/php.c
+++ b/parsers/php.c
@@ -682,6 +682,8 @@ static void parseHeredoc (vString *const string)
            int extra = EOF;

            c = getcFromInputFile ();
+           if (c == ' ' || c == '\t')
+               c = getcFromInputFile ();
            for (len = 0; c != 0 && (c - delimiter[len]) == 0; len++)
                c = getcFromInputFile ();

$ cat input.php
cat input.php
<?php
// Taken from https://github.com/universal-ctags/ctags/issues/2717
// submitted by <strong i="5">@jespinal</strong>
class LivingBeings {

    public function doSomething()
    {
        $foo = <<<FOO
        FOO;
    }

    public function doSomethingElse()
    {
    }
}
$ u-ctags -o - input.php
u-ctags -o - input.php
LivingBeings    input.php   /^class LivingBeings {$/;"  c
doSomething input.php   /^    public function doSomething()$/;" f   class:LivingBeings
$

masatake هذا ليس كافيًا ، لأن علامة النهاية كانت في السابق يجب أن تكون على سطر خاص بها ، بينما يرفع الإصدار الجديد هذا التقييد. لا أجد الشرح واضحا جدا:

يتجنب التطبيق الذي أقترحه هذه المشكلة عن طريق التحقق لمعرفة ما إذا كان هناك استمرار للعلامة التي تم العثور عليها ، وإذا كان الأمر كذلك ، فعندئذ إذا كان يشكل معرفًا صالحًا.

لكنني أقول أن هذا يعني أنه ما لم يكن هناك حرف معرف بعد السطر مسبوقًا بعلامة النهاية ، فهو بالفعل علامة إنهاء. لذا فإن END; هو إنهاء (نظرًا لأن العلامة هي END ) ، لكن ENDFOO ليس كذلك.

راجع للشغل ، نظرًا لأن هذا تغيير نحوي غير متوافق للخلف ، لا أعرف ما الذي نريد فعله حيال ذلك. لكنني أعتقد أنه إذا كانت PHP سعيدة بكسرها ، فيمكننا ذلك أيضًا ، خاصة أنه من غير المحتمل إلى حد ما أن تسبب مشكلة. من الناحية المثالية ، أعتقد أننا سنستخدم الصيغة الحالية لـ *.php[1-6] والصيغة الجديدة للبقية ، لكن هذا قد يكون مشكلة كبيرة بالنسبة لما يستحق.

jespinal ، هل تتحدث عن هذا التغيير: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes ؟

عذرًا ، masatake ، لسبب ما لم يتم

نعم ، أنا أتحدث عن هذا التغيير. ولكن تم تطبيق ذلك بالفعل في PHP 7.3 (الإصدار الثابت الحالي هو 7.4 ، والإصدار 8 في متناول اليد). لست متأكدًا من سبب عدم الإبلاغ عن ذلك مسبقًا مع الأخذ في الاعتبار قاعدة المستخدمين الواسعة لكل من ctags و PHP.

أقوم بإضافة بعض لقطات الشاشة لمقتطفات التعليمات البرمجية المستمدة من المثال السابق من أجل (نأمل) إلقاء بعض الضوء على ما يعتبرونه بناء جملة صالحًا / غير صالح فيما يتعلق ببنية heredoc / nowdoc الجديدة (RFC ليس واضحًا بدرجة كافية ، I فكر في).

في هذا المثال ، " TEXT " (الثاني) هو علامة النهاية. لذا ، فإن العنصر الثالث ' TEXT; عبارة عن سلسلة غير صالحة من الناحية النحوية في عرض المحلل اللغوي ، حيث يتوقع فقط فاصلة منقوطة أو فاصلة:

حالة مماثلة للحالة السابقة:

لو كانت فاصلة منقوطة أو فاصلة ، لكان محلل php سعيدًا. على سبيل المثال

        echo <<<TEXT
            some string 
        TEXT, 'some other string';

في نظر المحلل اللغوي ، هذا هو نفسه:

    echo 'some string', 'some other string';

المثال التالي هو مثال صالح ، حيث يعلم المحلل اللغوي أن ' TEXT ' و ' TEXTUAL ' هما سلسلتان مختلفتان:

إليك بعض المقتطفات غير الصالحة بسبب المسافة البادئة الخاطئة. على وجه التحديد ، بالنسبة إلى عبارة RFC: "إذا تم وضع مسافة بادئة لعلامة الإغلاق أكثر من أي سطور من الجسم ، فسيتم طرح ParseError:"

jespinal شكرًا ، ولكن إذا كان لديك نص معياري رابطmasatake ومعلوماتك: +1:

masatake لا أعدك بأي شيء بالنظر إلى الوقت القليل الذي أجده مؤخرًا ، لكنني سأحاول إلقاء نظرة على هذا قريبًا ما لم - لقد

راجع للشغل jespinal إذا لم يشتكي أحد ، أعتقد حقًا أنه بسبب وجود القليل جدًا من استخدام هذه البنية ، ونحن ندعم بناء الجملة قبل 7.3 ، لذا فإن الحالات الوحيدة التي قد يرى المرء فيها مشكلة هي استخدام بناء الجملة 7.3+ ، مما يعني استخدام neredoc / nowdoc في المقام الأول :)

كنت غير نشط لفترة من الوقت. لذلك لم أتوقع تلقي تعليق منك.
ولكن ، الآن نحصل على علامة "المخصصة ذاتيًا" منك. @ b4n ، شكرًا لك على العرض.

masatake لقد كنت حكيماً ألا تتوقع الكثير مني ، لأنني في الواقع لم أجد وقتًا للكثير من مساهمات UCtags / Geany مؤخرًا: محبط:. أحاول العثور على كيفية تخصيص الوقت هنا مرة أخرى ، لذلك آمل أن أكون أكثر نشاطًا مرة أخرى ، لكن لا يمكنني أن أعدك الآن.

ومع ذلك ، راجع # 2734 لإصلاح المشكلة المطروحة :)

شكرا لك!