En este proyecto, exploramos las aplicaciones de las pruebas de vulnerabilidad ante datos aleatorios o inesperados para probar el compilador de Kotlin. En un estudio anterior, encontramos bastantes errores en el compilador. Actualmente, trabajamos para ampliar las pruebas de vulnerabilidad ante datos aleatorios o inesperados a más componentes del compilador e incluirlas en el proceso de control de calidad del compilador.

Kex es nuestra plataforma de análisis de código de bytes de Java, que permite cargar código de bytes de Java, construir un modelo intermedio y analizarlo mediante solucionadores SMT. De momento, Kex se centra en la generación de pruebas, pero también estamos barajando usarlo para otras cosas como la reproducción de fallos, el análisis y la reparación de programas.

En este proyecto tratamos de comprender si la autocoherencia es una buena medida de la calidad del código generado por los LLM. Un LLM produce un resultado autocoherente si, ante la misma petición, genera soluciones que cumplen con una definición dada de coherencia. Dentro de este proyecto estamos utilizando pruebas diferenciales para medir la coherencia: todas las soluciones generadas deben comportarse de la misma manera en un conjunto de pruebas determinado o generado. Para generar las pruebas, aplicamos Kex en modo de generación de pruebas.

Se considera que los LLM son buenos para hacer conversiones entre diferentes lenguajes. Queremos comprender si esto es así con el problema de convertir configuraciones de compilación de Gradle de .gradle a .gradle.kts. Esto es especialmente aplicable al realizar la conversión desde la API más antigua de Groovy hacia la más reciente de Kotlin. Realizamos esto comparando el resumen antes y después de las configuraciones de compilación extraídas de Gradle a través de las herramientas de IntelliJ Platform.