Exclude unexposed classes from the extension_api.json

[dsnopek]

@Bromeon noticed that GDScriptNativeClass was included in the extension_api.json but that it wasn't possible to actually get that class at runtime. Looking at the code, it appears that GDScriptNativeClass isn't exposed (ie. there's no GDREGISTER_CLASS(GDScriptNativeClass) anywhere).

This PR adds a ClassDB::is_class_exposed() check in GDExtensionAPIDump::generate_extension_api() to ensure that unexposed classes aren't included in the extension_api.json.

Up until now, I think unexposed classes were mostly not included in the extension_api.json by accident: most simply weren't in ClassDB by the time that we were generating the extension_api.json.

Aside from GDScriptNativeClass, this change also removes the following other unexposed classes (at least for me - I did a diff of the extension_api.json with and without this PR):

• FramebufferCacheRD
• GDScriptEditorTranslationParserPlugin
• GLTFDocumentExtensionPhysics
• GLTFDocumentExtensionTextureWebP
• GodotPhysicsServer2D
• GodotPhysicsServer3D
• IPUnix
• MovieWriterMJPEG
• MovieWriterPNGWAV
• ResourceFormatImporterSaver
• UniformSetCacheRD

I'm not familiar with all of these classes, but I think they are all meant to be internal, and not interacted with directly.

[akien-mga]

I think this would resolve this FIXME in 4.0-stable.expected, which can then be removed:

Misc
----
Validate extension JSON: API was removed: classes/FramebufferCacheRD
Validate extension JSON: API was removed: classes/UniformSetCacheRD

FIXME: These aren't written when dumping the interface with a headless build
(since there's no RD backend in use). We need to fix this inconsistency somehow.

(those two files can be listed among the others which were intentionally unexposed)

See also:

• Classes that are exposed but lead to empty docs pages. #76918
• GDScriptNativeClass reported as Object but missing methods in GDScript #77567
• Editor C++ classes exposed to GDScript with empty documentation #79369

The same check may be needed in other places, such as the EditorHelp, or GDScript code completion.

I'm still unclear on when we want a class to be registered in ClassDB, but not exposed. I wonder if those are indeed meant to be skipped as done here, or whether they should not be in ClassDB in the first place. I guess their existence in ClassDB comes from using GDCLASS?

[dsnopek]

I'm still unclear on when we want a class to be registered in ClassDB, but not exposed. I wonder if those are indeed meant to be skipped as done here, or whether they should not be in ClassDB in the first place. I guess their existence in ClassDB comes from using GDCLASS?

An unexposed class is a class that has GDCLASS() but isn't registered via ClassDB::register_class(). It will still get added to ClassDB when the first instance of the class is created (which is how GDExtensionAPIDump ends up encountering these ones, they just happen to have instances created before it runs), but it's ClassInfo is added with the exposed flag set to false.

Personally, I think it makes sense for all classes descending from Object to use GDCLASS(). This way an instance of the class will be identified as being the right class (ie obj.get_class() returns the correct class name), as opposed to Godot acting as if it was an instance of its parent class. But I know there's classes in Godot that omit GDCLASS() on purpose, so that's just my opinion and is up for debate. :-)

However, for the purposes of this PR, I don't think we need to figure out if these specific classes should have used GDCLASS() or not. Unexposed classes are a feature of ClassDB, so even if it's not these specific classes, there can always be unexposed classes in ClassDB and we don't want any of them in the extension_api.json because unexposed classes can't be used from GDExtension.

[dsnopek]

I think this would resolve this FIXME in 4.0-stable.expected, which can then be removed

In my latest push, I've removed the "Misc" section and moved those down to be included with the other unexposed classes that are removed via this PR. Until we update the extension_api.json from Godot 4.0 to also exclude those (I guess after this change is cherry-picked?), the exceptions will still be needed.

[aaronfranke]

Those GLTF classes are indeed internal and do not need to be exposed at all.

[akien-mga]

Thanks!

[YuriSizov]

We've discuss this a bit, and it seems it's better to avoid cherry-picking this. While absolutely beneficial, it does introduce a change to the dumped API, and because of that to our compatibility checker. The changes here would make 4.1's 4.0-stable.expected deviate from master's 4.0-stable_4.1-stable.expected, which should in theory be in sync.