Same name between nullable and null-initialized variable and it's type leads to an error in codegen

[gordonxy]

Hello, first of all, thanks for this great piece of software.

I've encountered an issue when having a nullable and null-initialized variable with the same name as its type:

@JsonClass(generateAdapter = true)
data class OtherTestModel(
    val TestModel : TestModel? = null
)

Note-worthy here is that the TestModel class is also annotated to have a generated adapter by moshi:

@JsonClass(generateAdapter = true)
data class TestModel(
    val someVariable : Int,
    val anotherVariable : String,
)

In the build process in the code generation this leads to an error:

Expression in a class literal has a nullable type 'TestModel?', use !! to make the type non-nullable

This error is in the following code-snippet in the generated code:

val localConstructor: Constructor<OtherTestModel> = this.constructorRef ?:
        OtherTestModel::class.java.getDeclaredConstructor(TestModel::class.java, // <- this is the culprit
        Int::class.javaPrimitiveType, Util.DEFAULT_CONSTRUCTOR_MARKER).also { this.constructorRef =
        it }

I believe the Kotlin compiler sees TestModel here as the nullalble and null initialized variable instead of the class type, so if the generation could simply give the generated variable a different name it would sort itself out. This seems to be true given that when I rename the variable to testModel instead, the error does not appear. (In my case I can not rename this variable due to external constraints.)

Thanks! :)

[ZacSweers]

This is a tricky one, as we'd need to fully qualify the type or maybe prefix the variable name. I think something we could do is run all the property types' simple names first through a NameAllocator and then add local variables after that

@Egorand does that approach seem reasonable?

[Egorand]

I wonder if Kotlin compiler could be smarter here (and also whether a similar issue exists in Java) - in which case this might be something to report to Jetbrains. But I think that seeding NameAllocator with known types' simple names and running property names through it should fix the problem and won't be too annoying as a general solution.