Ctags: PHP heredoc (<<

@jespinal , você está falando sobre essa mudança: 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 isso não é suficiente, porque o marcador de finalização costumava estar em sua própria linha , enquanto a nova versão remove essa restrição. Não acho a explicação muito clara:

A implementação que estou propondo evita esse problema verificando se existe uma continuação do marcador encontrado e, em caso afirmativo, se forma um identificador válido.

mas eu diria que isso significa que, a menos que haja um caractere identificador após a linha prefixada com o marcador de terminação, é de fato um marcador de terminação. Então END; é uma rescisão (dado que o marcador é END ), mas ENDFOO não é.

BTW, como esta é uma alteração sintática incompatível com versões anteriores, não sei o que queremos fazer sobre isso. Mas eu acho que se o PHP está feliz em quebrá-lo, nós também podemos, especialmente porque é bastante improvável que cause problemas. Idealmente, acho que usaríamos a sintaxe atual para *.php[1-6] e a nova para o resto, mas isso pode ser muito problemático para o que vale a pena.

@jespinal , você está falando sobre essa mudança: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes ?

Desculpe, @masatake , por algum motivo não fui notificado de sua pergunta.

Sim, estou falando sobre essa mudança. Mas isso foi implementado no PHP 7.3 (a versão estável atual é 7.4, e a versão 8 está disponível). Não sei por que isso não foi relatado antes, considerando a vasta base de usuários de ctags e PHP.

Estou adicionando algumas capturas de tela de trechos de código derivados do exemplo anterior para (espero) lançar alguma luz sobre o que eles consideram sintaxe válida / inválida em relação à nova sintaxe heredoc / nowdoc (o RFC não é claro o suficiente, eu pensar).

Neste exemplo, ' TEXT ' (o segundo) é o marcador final. Portanto, o terceiro ' TEXT; é uma string sintaticamente inválida na visualização do analisador, pois seria esperado apenas um ponto e vírgula ou vírgula:

Um caso semelhante ao anterior:

Se fosse um ponto-e-vírgula ou vírgula, o analisador de php teria ficado feliz. Por exemplo

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

Aos olhos do analisador, isso é o mesmo que:

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

O seguinte é um exemplo válido, pois o analisador sabe que ' TEXT ' e ' TEXTUAL ' são duas strings diferentes:

Aqui estão alguns snippets inválidos devido ao recuo incorreto. Especificamente, para a instrução RFC: "Se o marcador de fechamento for indentado além de qualquer linha do corpo, um ParseError será lançado:"

@jespinal obrigado, mas se você tiver um texto normativo isso será ainda melhor :) É sempre difícil adivinhar a lógica com base apenas em alguns casos, ao passo que se tivermos o texto normativo podemos apenas implementá-lo e espero que funcione. E, na verdade, acho que temos o suficiente com o link de @masatake e suas informações: +1:

@masatake Eu não prometo nada dado o pouco tempo que tenho encontrado ultimamente, mas vou tentar dar uma olhada nisso logo, a menos que você chegue antes de mim :)

BTW @jespinal, se ninguém reclamou, eu realmente acho que é porque há muito pouco uso dessa sintaxe e oferecemos suporte à sintaxe pré-7.3, então os únicos casos em que se veria um problema é com o uso de sintaxe 7.3+, o que implica o uso de neredoc / nowdoc em primeiro lugar :)

Você ficou inativo por um tempo. Então, eu não esperava receber um comentário seu.
Mas, agora recebemos o sinal "auto-atribuído" de você. @ b4n , obrigado pela oferta.

@masatake, você foi sábio em não esperar muito de mim, já que eu realmente não encontrei tempo para muitas contribuições UCtags / Geany ultimamente: decepcionado:. Estou tentando descobrir como alocar tempo aqui novamente, então espero ser mais ativo novamente, mas não posso prometer ainda.

No entanto, consulte # 2734 para uma solução para o problema em questão :)

Obrigada!