Perl неглубокая проверка синтаксиса?то есть.не проверять синтаксис импорта

Question

Как я могу выполнить "мелкую" проверку синтаксиса для файлов perl.Стандарт perl -c полезен, но он проверяет синтаксис импорта.Иногда это хорошо, но не очень хорошо, когда вы работаете в репозитории кода и отправляете его в работающую среду, и у вас есть функция, определенная в репозитории, но еще не переданная в работающую среду.Не удается проверить функцию, потому что импортирует пути к ссылочной системе (т. Е. Использует Custom :: Project :: Lib qw (foo bar baz)).

Answer 1

Это практически невозможно, потому что импорт может влиять на синтаксический анализ следующего кода.Например, use strict делает так, чтобы голые слова не анализировались как строки (и изменяет правила использования имен переменных), use constant вызывает определение константных подпрограмм, а use Try::Tiny изменяет синтаксический анализ выражений, включающихtry, catch или finally (предоставив им & прототипов).В целом, любой модуль, который экспортирует что-либо в пространство имен вызывающего, может влиять на синтаксический анализ, потому что анализатор perl разрешает неоднозначность различными способами, когда имя ссылается на существующую подпрограмму, а не когда это не так.

Answer 2

Есть две проблемы с этим:

1. Как не выйти из строя -c, если отсутствуют необходимые модули?

   Есть два решения:

   A.Добавьте в производство поддельный / стаб модуль

   B.Во всех ваших модулях используйте специальную запись-ловушку @INC-подпрограммы (использование подпрограмм в @INC объясняется здесь ).Очевидно, в этом есть проблема с тем, что модуль НЕ завершится с ошибкой в ​​реальном рабочем режиме, если библиотеки отсутствуют - DoublePlusNotGood в моей книге.

2. Даже если бы вы могли как-то пропустить сбой на отсутствующих модулях, выСЛЕДУЕТ потерпеть неудачу при любом использовании идентификаторов, импортированных из отсутствующего модуля или явно используемых из пространства имен этого модуля.

   Единственное реалистичное решение этого - вернуться к # 1a и использовать модуль-заглушку, но этовремя, которое имеет объявленный и (при необходимости) экспортированный идентификатор для каждого открытого интерфейса.Например, бездействующие подпрограммы или фиктивные переменные.

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

   Но этот подход прекрасно работает для обычного "Java / C-like" ОО или процедурного кода, который вызывает только статически именованные предопределенные публичные подпрограммы, методы и обращается к экспортируемым переменным.

Answer 3

Я бы посоветовал включить репозиторий кода в проверку синтаксиса. perl -I/path/to/working/code/repo/local_perl/ -c или установите PERL5LIB=/path/to/working/code/repo/local_perl/ до запуска perl -c. Любой из этих вариантов должен позволять вам проверять свой рабочий код, предполагая, что он находится в структуре каталогов, аналогичной вашему действующему коду.

Answer 4

Вы смотрели в PPI?Я думаю, что он следует за импортом, однако, возможно, его можно было бы легче изменить, чтобы угадать, как выглядит имя функции.

Answer 5

Полагаю, вы можете создать заглушки для отсутствующих библиотек в вашей домашней папке.