Add support for indexed properties in api-generator

[silentorb]

Some of Godot's property getter/setters have an additional index parameter, specified with the index field of the property metadata.

For those properties the api-generator within godot-kotlin-jvm is not including the index arguments in the generated property code, causing the setters for indexed properties to throw exceptions.

The indexed getters seem to be working without the extra index property. I'm not sure how that is.

This PR adds code to api-generator's Property::generate so that the generated code includes the indexed arguments for properties that need them.

For example, the code generated for SpatialMaterial::albedoTexture (which has a hard-coded index of 0) looks like this after the PR:

  public open var albedoTexture: Texture?
    get() {
      TransferContext.writeArguments(JVM_INT to 0)
      TransferContext.callMethod(rawPtr,
          ENGINEMETHOD_ENGINECLASS_SPATIALMATERIAL_GET_ALBEDO_TEXTURE, OBJECT)
      return TransferContext.readReturnValue(OBJECT, true) as Texture?
    }
    set(`value`) {
      TransferContext.writeArguments(JVM_INT to 0, OBJECT to value)
      TransferContext.callMethod(rawPtr,
          ENGINEMETHOD_ENGINECLASS_SPATIALMATERIAL_SET_ALBEDO_TEXTURE, NIL)
    }

Where before those two writeArguments lines were:

TransferContext.writeArguments()

and

TransferContext.writeArguments(OBJECT to value)

Even though only the setters were throwing exceptions, I also added the index parameter to the getter because that seems like the more accurate call. I haven't been able to verify yet but maybe there is some additional code on the C++ side that is filling in the gaps for the indexed getter calls?

My understanding is that godot-kotlin-jvm is using Long instead of Int for interop, though in this case using Long for the indexed properties was failing while using Int is working. I'm guessing maybe that's because the index parameter is not a formally exposed element of the Godot API and is instead a lower-level implementation detail.

For the current version of the API this PR affects 32 generated files. I left the generated files out of the PR to keep the PR minimal but can add them if needed.

I've tested some of the indexed property cases and everything I have tested is working. I have not comprehensively tested every property affected by this PR.

[piiertho]

Hello ! That’s a good catch ! Thanks a lot !
What error did you have with Long ? This should work with it, JVM_INT is here only for convenience, it will send a long in buffer.
Can you please push modified classes ?

[silentorb]

@piiertho The generated code changes are now included.

The error I had been running into with Long was with the buffer writing where code was expecting a Long but receiving an Int. At the time I had though there must be some lower level API expecting an Int, but on further inspection the mismatch was with my own added code, which was using Int literals when it should have been using Long literals.

I updated my changes to consistently use Longs and that is working now.

After further testing, it turns out that I must have mixed up which builds I was testing when I thought the indexed getters were originally working, and after more testing can now confirm that the indexing problem does also apply to the getters so the changes in this PR are needed for both getters and setters.

For the record, here's a link to the code that is generating the code that is raising the error this PR is addressing: https://github.com/godotengine/godot/blob/3.4.2-stable/core/make_binders.py#L48-L53.

As a side note, when I peruse the affected properties, it looks like mostly less common Godot properties use this indexing mechanism. I've been using Godot Kotlin JVM for over six months and only recently ran into this issue.

[piiertho]

Build errors on windows are not from your side. I asked on an existing godot issue why this is happening: godotengine/godot#58595

Linux check is error we have because gpg key is repo private :/

Anyway, everything looks good to me.

[chippmann]

Thx a lot for the fix!

[piiertho]

@silentorb can you rebase branch on master ?

[silentorb]

@piiertho: The PR is rebased with the latest build changes.

[piiertho]

Thx for contribution !