compiler-construction - prueba - como hacer un interprete en java
Casos de prueba de compilador o cómo probar un compilador (7)
Los compiladores, como todo el software, también serían propensos a errores, errores lógicos.
¿Cómo se valida el resultado generado por el compilador? Por lo general, mi pregunta es (son)
¿Cómo validar que el código máquina generado es correcto?
Cómo asegurarse de que el código de máquina generado esté de acuerdo con la especificación del idioma.
¿Tiene sentido elegir un proyecto de código abierto (en C si también está escribiendo un compilador en C) para compilarlo a través del "compilador"? En ese caso también, cómo juzgar que el compilador se comporta como se esperaba.
¿Hay algún caso de prueba formal (literatura) proporcionado por el comité de estándares lingüísticos que un compilador "que cumple con el idioma" debe satisfacer?
¿Cuáles son las "certezas" seguras de que el problema en un programa compilado por un compilador es un error del compilador y no un error del programa?
- ¿Algún ejemplo donde los compiladores convencionales se confunden y compilan el código incorrecto?
Los enlaces a cualquier literatura serán apreciados.
El compilador de Eiffel es de código abierto y tiene una amplia biblioteca de casos de prueba y contratos de diseño interno.
GCC tiene un conjunto de pruebas bastante grande ( https://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites ). Está disponible en el SCM: https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite
Hay varias suites de prueba de compilador por ahí. Hemos tenido algo de suerte al usar el paquete de pruebas Plum Hall para un compilador de C. Consiste en un gran conjunto de código C escrito específicamente para evaluar el estándar de idioma. Verifica que el compilador puede manejar la sintaxis y la semántica del lenguaje.
Hubo una pregunta anterior relacionada con esto para C , pero se reduce a un conjunto de pruebas de compilación cuidadosamente escritas.
En cuanto a cuando los compiladores obtienen el código incorrecto, lo he acertado con bastante frecuencia en mi carrera profesional, gracias. Ha pasado cada vez menos con el tiempo, pero encontré un error en los compiladores de MS C ++ que apuntan a CLI esta semana.
La práctica general es crear un gran conjunto de pequeños programas que demuestren cada uno aspectos del compilador. Estos incluirán tanto el programa que compila como los que no deberían. En general, el ASM que sale del back end no está marcado, sino que se ejecuta el programa y se comprueba su salida. En cuanto a cómo asegurarse de que no haya errores en los casos de prueba: hágalos pequeños, como en 5-10 líneas cada uno.
Estos conjuntos de pruebas pueden ser muy grandes, como de cientos a miles de pruebas (por ejemplo, un conjunto de pruebas desactualizado para el lenguaje de programación D ) y generalmente incluyen uno o más casos de prueba por cada error que se haya informado.
Las suites de prueba buenas para idiomas reales son caras de crear y mantener. Hay una razón por la que el conjunto de pruebas Plum Hall , que es el estándar de la industria para ANSI C, es tan costoso.
La validación de la traducción de George Necula es una idea brillante pero también bastante costosa de implementar.
Lo único que es barato y fácil es esto: mantener un conjunto de pruebas de regresión, y cada vez que corrija un error en su compilador, ponga una prueba adecuada en sus suites de regresión . Con los compiladores, es increíble lo fácil que es seguir reintroduciendo el mismo error una y otra vez. Las adiciones disciplinadas a su suite de regresión evitarán eso, y no cuestan mucho.
Para la idea de compilar un gran proyecto de código abierto:
Podría tomar un proyecto que tenga un conjunto de pruebas. Luego compila el proyecto y su conjunto de pruebas y ve si las pruebas pasan. Para validar estos resultados, compile el proyecto y el conjunto de pruebas con otro compilador y vuelva a ejecutar las pruebas.