Neste projeto, estamos explorando as aplicações do fuzzing nos testes do novo compilador de Kotlin. Nas nossas pesquisas anteriores, encontramos um bom número de bugs no compilador. No momento, estamos trabalhando para estender o processo de fuzzing a outros componentes do compilador e incluindo esse processo no pipeline de controle de qualidade do compilador.

A Kex é a nossa plataforma de análise de bytecode em Java, que tem suporte a carregar o bytecode, criar um modelo intermediário e analisá-lo através de resolvedores de SMT. No momento, a Kex se concentra na geração de testes, mas também estamos pensando em usá-la para outras coisas, como a reprodução de crashes e análise e correção de programas.

Neste projeto, estamos tentando compreender se a autoconsistência é uma boa medida da qualidade do código gerado por LLMs. Um LLM produzirá um resultado autoconsistente se, dado um mesmo prompt, ele gerar soluções que satisfaçam a uma determinada definição de consistência. Neste projeto, estamos usando testagem diferencial para medir a consistência: todas as soluções geradas devem se comportar da mesma maneira em relação a um conjunto de testes determinado ou gerado. Para gerar os testes, aplicamos o Kex no modo de geração de testes.

LLMs são considerados bons para conversão entre linguagens diferentes. Queremos compreender se isso é verdadeiro para o problema da conversão de configurações de build do Gradle do formato .gradle para .gradle.kts.A maior aplicação disso é na conversão da API do Groovy, mais antiga, para a do Kotlin, mais recente. Fazemos isso comparando o resumo de antes e depois das configurações de build, extraídos do Gradle através das ferramentas da plataforma IntelliJ.