Another question is: does delegated property sette...

# compiler

[Gleb Minaev]

Another question is: does delegated property setter in IR sets delegate instead of value for the property?

The story is that I create on frontend a property suppliedTypesStorage with a delegate provided by a custom function fun suppliedTypesStorageDelegate(): ReadWriteProperty<Any?, Map<String, List<SuppliedType>>>. Then on backend, I set a value to the property in a class's constructor via

val suppliableClassSuppliedTypesStorageSetterIrSimpleFunctionSymbol = suppliableClassIrClassSymbol.getPropertySetter("suppliedTypesStorage")!!
...
val irClass = <an IrClass instance that describes the class which constructor I modify>
+irCall(suppliableClassSuppliedTypesStorageSetterIrSimpleFunctionSymbol).apply {
    arguments[0] = irGet(irClass.thisReceiver!!)
    arguments[1] = irCall(mapOfIrSimpleFunction).apply { ... }
}

The code compiles but throws class java.util.LinkedHashMap cannot be cast to class kotlin.properties.ReadWriteProperty during runtime. Looks like irCall(suppliableClassSuppliedTypesStorageSetterIrSimpleFunctionSymbol) is resolved not to the property setter but to the delegate's field setter. Do I miss something? Should I report it?

[Gleb Minaev]

Ah, I see that in IR the getter and setter do really get and set suppliedTypesStorage$delegate instead of using it as a delegate. I guess it's my mistake during FIR modification. But I don't know what's wrong with the property generation. The property is described here: https://github.com/lounres/Kone/blob/665ad7e50fad9e15231738213be5d33333cee14b/plug[…]iedTypes/fir/SuppliedTypesStoragePropertyGenerationExtension.kt

[Gleb Minaev]

I fixed it. Turns out that getter and setter that are generated in FIR via createMemberProperty treat backing field as a real backing field instead of delegate field. So I just replaced them with `null`s in FIR and generated them manually in IR.