Можно ли статически анализировать Perl?

Perl имеет четко определенную фазу «времени компиляции», за которой следует четко определенная фаза «времени выполнения». Однако есть способы перехода от одного к другому. Многие динамические языки имеют eval конструкции, позволяющие компилировать новый код на этапе выполнения; в Perl возможно и обратное, и это распространено. Блоки BEGIN (и неявный блок BEGIN, вызванный блоком use) вызывают временную фазу выполнения во время компиляции. Блок BEGIN выполняется, как только он скомпилирован, вместо ожидания компиляции остальной части единицы компиляции (т. е. текущего файла или текущего eval). Поскольку BEGIN запускаются до компиляции кода, следующего за ними, они могут влиять на компиляцию следующего кода практически любым способом (хотя на практике основное, что они делают, — это импорт или определение подпрограмм или включение строгости или предупреждений).

use Foo; в основном эквивалентен BEGIN { require foo; foo->import(); }, а требование (как и eval STRING) является одним из способов вызвать время компиляции из среды выполнения, что означает, что теперь мы находимся внутри времени компиляции внутри времени выполнения внутри времени компиляции, и все это рекурсивно.

В любом случае, для разрешимости разбора Perl это сводится к тому, что, поскольку на компиляцию одного бита кода может влиять выполнение предшествующего фрагмента кода (который теоретически может сделать что угодно), у нас возникла проблема с остановкой; единственный способ правильно проанализировать данный файл Perl вообще — это запустить его.

В Perl есть блоки BEGIN, которые запускают пользовательский код Perl во время компиляции. Этот код может повлиять на смысл другого компилируемого кода, что делает «невозможным» разбор Perl.

Например, код:

sub foo { return "OH HAI" }

"действительно":

BEGIN {
    *{"${package}::foo"} = sub { return "OH HAI" };
}

Это означает, что кто-то может написать на Perl так:

BEGIN {
    print "Hi user, type the code for foo: ";
    my $code = <>;
    *{"${package}::foo"} = eval $code;
}

Очевидно, что ни один инструмент статического анализа не может угадать, какой код собирается ввести здесь пользователь. (И если пользователь скажет sub ($) {} вместо sub {}, это даже повлияет на то, как вызовы foo интерпретируются в остальной части программы, что может привести к сбою синтаксического анализа.)

Хорошая новость заключается в том, что невозможные случаи очень краеугольные; технически возможно, но почти наверняка бесполезно в реальном коде. Так что, если вы пишете инструмент статического анализа, это, вероятно, не доставит вам проблем.

Честно говоря, у каждого достойного языка есть эта проблема или что-то подобное. В качестве примера бросьте ваш любимый код-проходчик на этот код Lisp:

(iter (for i from 1 to 10) (collect i))

Вы, вероятно, не можете предсказать, что это цикл, который создает список, потому что макрос iter непрозрачен, и для его понимания потребуются специальные знания. Реальность такова, что это раздражает в теории (я не могу понять свой код, не запустив его или, по крайней мере, не запустив макрос iter, который никогда не перестанет выполняться с этим вводом), но очень полезно на практике (итерация проста для программисту писать, а будущему программисту читать).

Наконец, многие люди думают, что в Perl отсутствуют инструменты статического анализа и рефакторинга, как в Java, из-за относительной сложности его разбора. Я сомневаюсь, что это правда, я просто думаю, что в этом нет нужды и никто не удосужился это написать. (Линт нужен, например, Perl::Critic.)

Любой статический анализ Perl, который мне нужно было выполнить для генерации кода (некоторые макросы emacs для поддержки счетчиков тестов и Makefile.PL), работал нормально. Могут ли странные угловые случаи сбить мой код? Конечно, но я не изо всех сил пишу код, который невозможно поддерживать, хотя мог бы.

Люди использовали много слов для объяснения различных фаз, но на самом деле это очень просто. При компиляции исходного кода Perl интерпретатор Perl может в конечном итоге запустить код, который изменяет способ синтаксического анализа остального кода. Статический анализ, который не запускает код, пропустит это.

В этом посте Perlmonks Джеффри рассказывает о своих статьях в The Perl Review, в которых содержится гораздо больше подробностей, включая пример программа, которая не анализирует одинаково каждый раз, когда вы ее запускаете.

C++ имеет аналогичную проблему в своей системе шаблонов, но это не мешает компиляторам компилировать его. Они просто вырвутся наружу или будут работать вечно в самых крайних случаях, где применим такой аргумент.

В Perl есть фаза компиляции, но она отличается от большинства обычных фаз компиляции, когда речь идет о коде. Лексер Perl превращает код в токены, затем синтаксический анализатор анализирует токены и формирует дерево операций. Однако блоки BEGIN {} могут прервать этот процесс и позволить вам выполнить код. При выполнении use. Все блоки BEGIN выполняются раньше всего, что дает вам возможность устанавливать модули и пространства имен. Во время общей «компиляции» сценария вы, скорее всего, будете использовать Perl, чтобы определить, как должен выглядеть модуль Perl после его завершения. sub, bare, подразумевает добавление его в glob для пакета, но это не обязательно. Например, это (хоть и странный) способ настройки методов в модуле:

package Foo;

use strict;
use warnings;
use List::Util qw/shuffle/;

my @names = qw(foo bar baz bill barn);
my @subs = (
    sub { print "baz!" },
    sub { die; },
    sub { return sub { die } },
);
@names = shuffle @names;
foreach my $index (0..$#subs) {
   no strict 'refs';
   *{$names[$index]} = $subs[$index];
}

1;

Вы должны интерпретировать это, чтобы даже знать, что оно делает! Это не очень полезно, но это не то, что вы можете определить заранее. Но это 100% правильный perl. Несмотря на то, что этой функцией можно злоупотреблять, она также может выполнять отличные задачи, например, создавать сложные сабвуферы, которые программно выглядят очень похожими. Кроме того, трудно точно знать, что все делает.

Это не значит, что Perl-скрипт нельзя «скомпилировать» — в Perl компиляция просто определяет, как в данный момент должен выглядеть модуль. Вы можете сделать это с помощью

perl -c myscript.pl

и он сообщит вам, сможет ли он добраться до точки, где он начнет выполнение основного модуля. Вы просто не можете просто знать, глядя на это «статически».

Однако, как показывает PPI, мы можем приблизиться к этому. Очень близко. Достаточно близко, чтобы делать очень интересные вещи, такие как (почти статический) анализ кода.

Таким образом, «время выполнения» становится тем, что происходит после выполнения всех BEGIN блоков. (Это упрощение; это гораздо больше. См. perlmod для получения дополнительной информации.) Это по-прежнему выполняется код perl, но это отдельная фаза выполнения, выполняемая после выполнения всех блоков с более высоким приоритетом.

chromatic опубликовал несколько подробных статей в своем блоге Modern::Perl:

• Как работает программа Perl 5
• Об разборе Perl 5