In this project, we’re exploring the applications of fuzzing for testing the Kotlin compiler. In our previous research, we found quite a few bugs in the compiler. We are currently working on extending the fuzzing process to even more compiler components and including it in the compiler quality assurance pipeline.

Kex is our Java bytecode analysis platform, which supports loading Java bytecode, building an intermediate model, and analyzing it via SMT solvers. At the moment, Kex focuses on test generation, but we’re also considering using it for other things like crash reproduction, program analysis, and repair.

In this project we are trying to understand whether self-consistency is a good measure of the quality of LLM-generated code. An LLM produces a self-consistent result if, given the same prompt, it generates solutions meeting a given definition of consistency. Within this project we are using differential testing to measure consistency: all generated solutions should behave the same way on a given or generated test suite. To generate tests, we apply Kex in test generation mode.

LLMs are considered good at converting between different languages. We want to understand if this is true for the problem of converting Gradle build configurations from .gradle to .gradle.kts. This is most applicable when converting from the older Groovy API to using the newer Kotlin one. We do this by comparing the abstract before and after build configurations extracted from Gradle via the IntelliJ Platform tools.