Perl prueba de sintaxis superficial? es decir. no compruebe la sintaxis de las importaciones

Question

¿Cómo puedo realizar una verificación de sintaxis "superficial" en los archivos perl. El estándar perl -c es útil, pero verifica la sintaxis de las importaciones. Esto a veces es bueno pero no excelente cuando trabajas en un repositorio de código y lo empujas a un entorno en ejecución y tienes una función definida en el repositorio pero que aún no se ha enviado al entorno en ejecución. Falla al verificar una función porque las rutas del sistema de referencia de las importaciones (es decir, usan Custom :: Project :: Lib qw (foo bar baz)).

Answer 1

Prácticamente no se puede hacer, porque las importaciones tienen la capacidad de influir en el análisis del código que sigue. Por ejemplo use strict lo hace de manera que barewords no se analizan como cadenas (y cambia las reglas de cómo los nombres de variables se puede utilizar), use constant provoca constantes submarinos a ser definidos, y use Try::Tiny cambia el análisis sintáctico de expresiones que implican try, catch o finally (dándoles prototipos &). De manera más general, cualquier módulo que exporte algo en el espacio de nombres de la persona que llama puede influir en el análisis porque el analizador de perl resuelve la ambigüedad de diferentes maneras cuando un nombre hace referencia a una subrutina existente que cuando no lo hace.

Answer 2

Supongo que puede hacer stubs para las bibliotecas que faltan en su carpeta de inicio.

Answer 3

Hay dos problemas con este:

1. Cómo no fallar -c si los módulos necesarios están perdiendo?

   hay dos soluciones:

   A. Añadir un módulo falso/ramal en la producción

   B. En todos sus módulos, utilice un cajón de sastre entrada especial @INC subrutina (usando submarinos en @INC es explicado here). Obviamente, esto tiene el problema de que el módulo NO falle en el tiempo de ejecución real de producción si faltan las bibliotecas: DoublePlusNotGood en mi libro.

2. Incluso si de alguna manera se saltara el fallo en los módulos faltantes, TODAVÍA fallaría en el uso de los identificadores importados del módulo faltante o se usaría explícitamente en el espacio de nombres de ese módulo.

   La única solución realista para esto es volver al n. ° 1a y usar un módulo falso, pero esta vez tiene un identificador declarado y (según sea necesario) exportado para cada interfaz pública. P.ej. no hacer nada o variables ficticias.

   Sin embargo, a pesar de que se producirá un error en algunos módulos avanzados que determinan de forma dinámica qué crear en su propio espacio de nombres y qué exportar en tiempo de ejecución (y el código de llamada podría determinar dinámicamente el cual submarinos para llamar - diablos, a veces qué módulos importar).

   Pero este enfoque funcionaría perfectamente para el código OO normal de tipo "Java/C" o el código de procedimiento que solo llama a los subs públicos predefinidos de forma estática, a los métodos y accede a las variables exportadas.

Answer 4

Sugeriría que es mejor incluir el depósito de código en la comprobación de sintaxis. perl -I/path/to/working/code/repo/local_perl/ -c o establecer PERL5LIB=/path/to/working/code/repo/local_perl/ antes de ejecutar perl -c. Cualquiera de las opciones debería permitirle verificar su código de trabajo, suponiendo que lo tiene en una estructura de directorios similar a su código en vivo.

Answer 5

¿Has mirado en PPI? Creo que sigue las importaciones, sin embargo, tal vez podría modificarse más fácilmente para adivinar lo que parece un nombre de función.