When I use `FirDeclarationGenerationExtension.getCallableNamesForClass` I return with a `Set` . Howe...

# compiler

[Tóth István Zoltán]

When I use FirDeclarationGenerationExtension.getCallableNamesForClass I return with a Set . However, the order of the declarations would be important as one of the properties I generate use another I generate. The set does not keep the order, so, my code fails with Parameter specified as non-null is null. Should I reorder the declarations? Or do I do something wrong?

[dmitriy.novozhilov]

How this property depends on another?
I see only two cases:
• you generate the property with anonymous object in initializer and want to use it in the second property (which is quite a weird case)
• you generate the body of the property in the frontend, which is not recommended

[Tóth István Zoltán]

I generate the backing field of the property in backend IR. Only the declaration is generated in FIR. The value of the first property is result of a call that gets a constant string and returns an instance. The value of the second property uses the value of the first one.

[dmitriy.novozhilov]

The value of the second property uses the value of the first one.

Do you mean it is used in the initializer?

[Tóth István Zoltán]

No, the initializer of the second calls the property getter of the first:

irCall(
   companionClass.propertyGetter { Strings.ADAT_METADATA },
   irGet(companionClass.thisReceiver !!)
)

[Tóth István Zoltán]

So, at the end it is like this, but generated.

companion object {
  val a = 12
  val b = a + 12
}

[dmitriy.novozhilov]

And the problem is that after fir2ir those properties are generated in reversed order, right?

[Tóth István Zoltán]

Yes. As I return with a set, there is no guarantee for the order.

[dmitriy.novozhilov]

You can reorder properties in IrClass.declarations manually

[Tóth István Zoltán]

Yes, I coded that just now, it works.

[Tóth István Zoltán]

Thanks.