Kontrola płytkiej składni Perla? to znaczy. nie sprawdzaj składni importu

Question

Jak mogę wykonać "płytkie" sprawdzanie składni w plikach perla. Standardowy perl -c jest przydatny, ale sprawdza składnię importu. Czasem jest to miłe, ale nie świetne, gdy pracujesz w repozytorium kodu i przenosisz do działającego środowiska, a masz funkcję zdefiniowaną w repozytorium, ale jeszcze nie przekazaną do działającego środowiska. Nie powiedzie się sprawdzanie funkcji, ponieważ ścieżki systemowe odniesienia importu (tj. Użyj Custom :: Project :: Lib qw (foo bar baz)).

Answer 1

Nie można praktycznie zrobić, ponieważ import ma możliwość wpływania na parsowanie kodu, który następuje. Na przykład use strict czyni go tak, gołe słowa nie są analizowane jako ciągi znaków (i zmienia zasady jak zmienna nazwy mogą być używane), use constant powoduje stałe subs być zdefiniowane i use Try::Tiny zmienia parse wyrażeń udziałem try, catch lub finally (dając im prototypy &). Mówiąc bardziej ogólnie, dowolny moduł, który eksportuje cokolwiek do przestrzeni nazw wywołującego, może wpływać na parsowanie, ponieważ parser perl rozróżnia niejednoznaczność na różne sposoby, gdy nazwa odwołuje się do istniejącego podprocedury, niż gdy nie.

Answer 2

Zgaduję, że można utworzyć stubs dla brakujących bibliotek w katalogu domowym.

Answer 3

Istnieją dwa problemy z tym:

1. Jak nie fail -c jeśli wymagane moduły brakuje?

   Istnieją dwa rozwiązania:

   A. Dodaj fałszywy moduł/odgałęzienie w produkcji

   B. We wszystkich modułach, użyć specjalnego catch-all wpis @ INC podprogramu (przy użyciu kanapki w @INC jest wyjaśniono here). To oczywiście ma problem z tym, że moduł NIE zawiedzie w rzeczywistym środowisku wykonawczym, jeśli brakuje bibliotek - DoublePlusNotGood w mojej książce.

2. Nawet jeśli w jakiś sposób można pominąć brakujące moduły, nadal nie można użyć identyfikatorów zaimportowanych z brakującego modułu lub użyć jawnie z przestrzeni nazw tego modułu.

   Jedynym realistycznym rozwiązaniem jest powrót do # 1a i użycie fałszywego modułu pośredniczącego, ale tym razem, który ma zadeklarowany i (w razie potrzeby) wyeksportowany identyfikator dla każdego interfejsu publicznego. Na przykład. niepoprawne zmienne lub zmienne atrapa.

   Jednak nawet to nie powiedzie się dla niektórych zaawansowanych modułów dynamicznie określają co do stworzenia własnej przestrzeni nazw, a co do eksportu w czasie wykonywania (a kod dzwoniący mógł dynamicznie określić, które subs zadzwonić - Heck, czasami, które moduły importować).

   Ale to podejście będzie działać dobrze w przypadku zwykłego "OO/podobnego do C" OO lub kodu proceduralnego, który wywołuje tylko statycznie nazwane predefiniowane publiczne subskrypcje, metody i dostęp do eksportowanych zmiennych.

Answer 4

Sugerowałbym, że lepiej włączyć repozytorium kodu do sprawdzania składni. perl -I/path/to/working/code/repo/local_perl/ -c lub ustaw PERL5LIB=/path/to/working/code/repo/local_perl/ przed uruchomieniem perl -c. Każda z tych opcji powinna umożliwić ci sprawdzenie kodu działającego, zakładając, że masz go w strukturze katalogów podobnej do twojego aktywnego kodu.

Answer 5

Czy zapoznałeś się z PPI? Wydaje mi się, że podąża za importowaniem, ale być może łatwiej byłoby go zmodyfikować, aby odgadnąć, co wygląda jak nazwa funkcji.