-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDScript: Improve DocGen #80745
GDScript: Improve DocGen #80745
Conversation
df593a9
to
9952eb2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me overall, but didn't review in depth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a couple of minor suggestions, none of which are super critical, but I do think they make the code a bit more readable.
Everything else seems to make sense upon a read of the code. I'm having trouble compiling atm, so I can't test this out unfortunately. But I know any regressions will be fixed quickly since this is @dalexeev 's work :)
I'll try to test this once I manage to get stuff compiling again. I'll use the set of scripts from #72095. We should expand those to now encompass signals as well as arrays!
if (m_var->initializer->is_constant) { | ||
prop_doc.default_value = m_var->initializer->reduced_value.get_construct_string().replace("\n", "\\n"); | ||
} else { | ||
prop_doc.default_value = "<unknown>"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we say <not constant>
here instead? At least it explains why a specific value is not known.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just copied this from function signature hint. If we want to change this, then we need to do it here as well:
godot/modules/gdscript/gdscript_editor.cpp
Lines 720 to 722 in 5444afa
if (par->initializer) { | |
String def_val = "<unknown>"; | |
switch (par->initializer->type) { |
More options: <non-constant>
, <non-const-expr>
, <dynamic>
, <unresolved>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally really like <non-const-expr>
for some reason! I just feel like it's worth explaining why something is unknown, as opposed to just stating that it is. That way people can more easily and immediately understand what's happening.
I don't think changing gdscript_editor.cpp
would lead to significant compat breaking, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit ugly in my opinion because of the two hyphens and longer text. I would choose <unknown>
, <dynamic>
or <non-constant>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your own, and my opinion is certainly very subjective. I don't think <unknown>
captures the reason why a value can't be written. I think <dynamic>
hints at it but isn't the most explicit, whereas <non-constant>
is the clearest to me, though I agree it isn't the prettiest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep <unknown>
for now since we haven't reached a consensus and there is a precedent with signature hint. We can fix this later or maybe some other reviewer will give their opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, sounds good! 👍
9952eb2
to
34d4328
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good! I am still not able to test due to compilation errors, but like I said before, I know @dalexeev is super efficient at fixing any regressions!
if (m_var->initializer->is_constant) { | ||
prop_doc.default_value = m_var->initializer->reduced_value.get_construct_string().replace("\n", "\\n"); | ||
} else { | ||
prop_doc.default_value = "<unknown>"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, sounds good! 👍
Thanks! |
Replace
_property_info_from_datatype()
with_doctype_from_gdtype()
to get the type info more universally, without intermediate conversion toPropertyInfo
/MethodInfo
usingDocData
's static methods, since this has issues with custom types.<unknown>
if the value is not a constant expression).Variant
instead of inferred weak type.static
qualifier to static methods.CC @anvilfolk