(macOS) Godot Editor forgets about GDExtension properties on extension reload, depending on the .gdextension file.

[Ivorforce]

Tested versions

Reproducible in Godot 4.3.

System information

Godot v4.3.stable - macOS 13.6.7 - Vulkan (Forward+) - dedicated AMD Radeon RX 6600 XT - 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 Threads)

I have not tested 4.4-dev in-depth yet.

Issue description

The format of the .gdextension file currently affects how 'well' the Godot editor is able to reload a GDExtension.
In the case that it is 'improperly' reloaded, the editor forgets about all properties / functions of the extension. Class names are retained. When the game is launched, it works as expected in all cases.

Example of an error screen:

--- Debugging process stopped ---
  res://main.gd:6 - Parse Error: Static function "test_function()" not found in base "GDScriptNativeClass".
  res://main.gd:6 - Parse Error: Static function "test_function()" not found in base "GDScriptNativeClass".
[...]

Cases

At this point, I am reasonably sure I can properly categorize the behavior into 3 camps:

When pointing directly to a .framework bundle, in all cases the editor forgets about the properties after a single click. It probably reloads instantly and fails the reload:

# All these cases behave the same way:
macos/numdot.macos.template_debug.x86_64.framework
./macos/numdot.macos.template_debug.x86_64.framework
res://addons/numdot/macos/numdot.macos.template_debug.x86_64.framework
res://./addons/numdot/macos/numdot.macos.template_debug.x86_64.framework

When pointing to a binary directly, the editor retains knowledge of the properties until the binary is rebuild. Then, it fails the reload:

# All these cases behave the same way:
macos/numdot.macos.template_debug.x86_64.framework/numdot.macos.template_debug.x86_64
res://addons/numdot/macos/numdot.macos.template_debug.x86_64.framework/numdot.macos.template_debug.x86_64
macos/numdot.macos.template_debug.x86_64.dylib
res://addons/numdot/macos/numdot.macos.template_debug.x86_64.dylib

When pointing to the binary directly, using a path that starts with ./, knowledge of the binary is retained. However, changes to the documentation are only reloaded when the editor is unfocused and focused again:

# These cases behave the same way:
./macos/numdot.macos.template_debug.x86_64.framework/numdot.macos.template_debug.x86_64
res://./addons/numdot/macos/numdot.macos.template_debug.x86_64.framework/numdot.macos.template_debug.x86_64
./macos/numdot.macos.template_debug.x86_64.dylib
res://./addons/numdot/macos/numdot.macos.template_debug.x86_64.dylib

Steps to reproduce

1. Create a blank gdextension with https://github.com/godotengine/godot-cpp
2. Register a static method via godot::ClassDB::bind_static_method("GDExample", D_METHOD("example_function"), &GDExample::example_function);
3. Open the godot editor
4. Run the game
5. Observe the amnesia

Minimal reproduction project (MRP)

https://github.com/Ivorforce/gdextension-staticmethod-amnesia

[Ivorforce]

Update: I think I have figured out the cause.

Ever since I updated the macos binaries to be .dylib suffix, the ingame editor is responsive again, and doesn't forget about the classes.

I have created a PR for the template to account for this problem (godotengine/godot-cpp-template#49). However, this PR still needs to stay open, because it's still a bug even if it has a workaround: If the file suffix is incorrect, the extension unloads in the editor (at least on macOS).

[Ivorforce]

I cannot reproduce this bug with Godot 4.4-dev3 as well as custom built master branch. It's possible it's been fixed already, just not released in 4.3 yet?

[Ivorforce]

Alright, I think I have all the information together on this issue that there is to have. I have edited the issue description accordingly.

See also related godotengine/godot-cpp#1681.