Dans le cadre de ce projet, nous allons explorer les applications des tests à données aléatoires (fuzzing) pour la vérification du compilateur Kotlin. Au cours de nos recherches précédentes, nous avons trouvé un nombre considérable de bugs dans le compilateur. Nous travaillons actuellement sur l'extension du processus de tests à données aléatoires à un nombre encore plus nombreux de composants de compilateur et allons les inclure dans son pipeline d'assurance qualité.

Kex est notre plateforme d'analyse du bytecode Java, qui prend en charge le chargement du bytecode Java, la création d'un modèle intermédiaire et son analyse au moyen de solveurs SMT. Actuellement, Kex porte essentiellement sur la génération de tests, mais nous envisageons aussi de l'utiliser pour d'autres choses, telles que la reproduction de pannes, l'analyse de programmes et la réparation.

Dans ce projet, nous cherchons à déterminer si l'auto-cohérence est une bonne mesure de la qualité du code généré par un LLM. Un LLM produit un résultat auto-cohérent si, pour un même prompt, il génère des solutions correspondant à une définition donnée de la cohérence. Dans ce projet, nous utilisons des tests différentiels pour mesurer la cohérence : toutes les solutions générées doivent se comporter de la même façon pour une suite de tests donnée ou générée. Pour générer des tests, nous appliquons Kex en mode génération de tests.

Les LLM sont considérés comme un bon outil de conversion entre différents langages. Nous souhaitons vérifier si cela est vrai pour la conversion de configurations de build Gradle de .gradle à .gradle.kts. Cela est surtout pertinent pour passer de l'ancienne API Groovy à la nouvelle API Kotlin. Pour cela, nous comparons l'extrait avant et après les configurations de build extraites de Gradle via les outils de la plateforme IntelliJ.