GDExtension documentation no longer updating

[modernmenace]

Godot version

4.2.dev6

System information

Reproducible on Windows 10 & MacOS Sonoma

Issue description

After updating from 4.1.1 stable to 4.2.dev6 the auto generated documentation for GDExtension classes is no longer updated after adding/changing/removing functions, enums, or properties.

At first I thought this had because of an oversight in the new hot reload functionality (this is great by the way), but the documentation is not updated even after restarting the editor. I have not yet found a way to get the documentation to update in 4.2.

Steps to reproduce

1. View documentation for a GDExtension class
2. Bind a new function to that class
3. View the documentation again and notice that no new entry has been added for that function

Minimal reproduction project

N/A

[dsnopek]

Hm. I don't think GDExtension is specifically doing anything for editor documentation. This sounds more like it could be some issue with the editor caching documentation too long or something like that?

[LanzaSchneider]

@dsnopek
Whenever I delete the file "editor_data\cache\editor_doc_cache.res" and re-run the editor, the documentation is updated!
I hope this information helps with this issue...

[dsnopek]

Thanks, that is helpful!

I wonder if we should somehow not put the GDExtension docs into the doc cache? Or, if the doc cache could get rebuilt when the modification timestamp changes on any GDExtensions? Although, that last one may be tricky to do, because we have to worry about two files for each extension: the .gdextension file and the specific library that will be loaded for the current platform and feature tags.

[akien-mga]

CC @RandomShaper

[akien-mga]

Tested locally, I can confirm the issue, though it's worse for me than simply not updating for new methods and functions - GDExtension documentation doesn't get displayed at all (ctrl-clicking on the name of a GDExtension class leads to an empty page).

I guess it depends on whether the GDExtension was loaded when the editor doc cache was generated. It doesn't get invalidated when new GDExtensions are added / GDExtensions change.

I confirm that this hack fixes it:

diff --git a/editor/editor_help.cpp b/editor/editor_help.cpp
index 0ab6e20b01..0147dfea68 100644
--- a/editor/editor_help.cpp
+++ b/editor/editor_help.cpp
@@ -2416,6 +2416,9 @@ void EditorHelp::_gen_doc_thread(void *p_udata) {
 }
 
 void EditorHelp::generate_doc(bool p_use_cache) {
+	// Temporarily disable use of cache for pre-RC stabilization.
+	p_use_cache = false;
+
 	OS::get_singleton()->benchmark_begin_measure("EditorHelp::generate_doc");
 	if (doc_gen_use_threads) {
 		// In case not the first attempt.

So this was indeed re-introduced by #78615.

---

To test, you can use Threen. The demo project there should work in 4.2 after copying the files from the 1.0.1 release to the bin folder.

[Riteo]

@dsnopek

I wonder if we should somehow not put the GDExtension docs into the doc cache?

Honestly, I think that due to the extremely variable nature of GDExtensions or any other form of plug in it's not worth it to cache a few classes compared to the whole engine doc, so I agree that we should exclude it from the cache altogether.

The documentation is cached immediately after regeneration, so it should be possible.

#83747 actually works on this by proposing that, once we generate the documentation cache, we can add stuff on the main documentation object as long as we don't cache it anymore (unless we regen it from scratch).

Said PR already improves extension doc handling quite a lot as it has the ability to clean up doc data on extension unloading.

Based on top of it, the only changes needed would be to change the doc generation routine to ignore extension classes and then the only piece left is to find a way to generate them.

I really like the idea of just implementing a ClassDB-based fallback in the EditorHelp::_attempt_doc, which is pretty much the place where the editor asks itself: "should I call docgen there?", but is only available for ScriptLanguage docs (such as GDScript docgen).

Despite it adding a new feature (the GDExt inteface), the relevant pieces for this issues are not required to be exposed to the user so I could try making a PR that takes them and implements the above if this approach looks sound.