Controllo sintassi superficiale Perl? vale a dire. non controllare la sintassi delle importazioni

Question

Come posso eseguire un controllo sintattico "superficiale" sui file perl. Lo standard perl -c è utile ma controlla la sintassi delle importazioni. Questo a volte è bello ma non eccezionale quando si lavora in un repository di codice e si spinge in un ambiente in esecuzione e si ha una funzione definita nel repository ma non ancora spinto all'ambiente in esecuzione. Non riesce a controllare una funzione perché i percorsi del sistema di riferimento delle importazioni (ad esempio, utilizzare Custom :: Project :: Lib qw (foo bar baz)).

Answer 1

Non può praticamente essere fatto, perché le importazioni hanno la capacità di influenzare l'analisi del codice che segue. Per esempio use strict fa sì che bareword non vengono analizzati come stringhe (e cambia le regole per come nomi variabile può essere utilizzato), use constant provoca sub costanti da definire, e use Try::Tiny cambia il parsing di espressioni che coinvolgono try, catch o finally (dando loro i prototipi &). Più in generale, qualsiasi modulo che esporta qualcosa nel namespace del chiamante può influenzare l'analisi perché il parser perl risolve l'ambiguità in modi diversi quando un nome fa riferimento a una subroutine esistente rispetto a quando non lo fa.

Answer 2

Immagino che potresti creare degli stub per le librerie mancanti nella tua cartella home.

Answer 3

Ci sono due problemi con questo:

1. Come non fallire -c se i moduli necessari sono mancanti?

   ci sono due soluzioni:

   A. Aggiungere un falso modulo/stub nella produzione

   B. In tutti i moduli, usare uno speciale catch-all ingresso @INC subroutine (usando sottomarini in @INC è spiegato here). Questo ovviamente ha il problema di far fallire il modulo nel runtime di produzione reale se mancano le librerie - DoublePlusNotGood nel mio libro.

2. Anche se si potesse saltare inavvertitamente il mancato funzionamento dei moduli mancanti, si ANTERRÀ in ogni caso l'utilizzo degli identificatori importati dal modulo mancante o utilizzati in modo esplicito dallo spazio dei nomi di quel modulo.

   L'unica soluzione realistica a questo è tornare al # 1a e utilizzare un modulo di stub falso, ma questa volta uno che ha un identificatore esportato e (se necessario) esportato per ogni interfaccia pubblica. Per esempio. do-nothing subs o dummy variables.

   Tuttavia, anche questo avrà esito negativo per alcuni moduli avanzati che determinano in modo dinamico quello di creare nel proprio spazio dei nomi e cosa esportare in fase di esecuzione (e il codice chiamante potrebbe determinare in modo dinamico, che subs chiamare - diamine, a volte quali moduli importare).

   Ma questo approccio funzionerebbe bene per normale OO "Java/C-like" o codice procedurale che richiama solo sottotitoli, metodi e accessi pubblici predefiniti con nome staticamente esportati.

Answer 4

Suggerirei che è meglio includere il repository del codice nel controllo della sintassi. perl -I/path/to/working/code/repo/local_perl/ -c o impostare PERL5LIB=/path/to/working/code/repo/local_perl/ prima di eseguire perl -c. Entrambe le opzioni dovrebbero consentire di controllare il tuo codice di lavoro, assumendo che tu abbia in una struttura di directory simile al tuo codice live.

Answer 5

Hai esaminato PPI? Penso che segua le importazioni, tuttavia potrebbe essere più facilmente modificato per indovinare quello che sembra un nome di funzione.