Add Variant to type autocompletion by mu3657 · Pull Request #111878 · godotengine/godot

mu3657 · 2025-10-21T09:29:11Z

This PR addresses an issue where the Variant meta-type was missing from the autocompletion suggestions in various GDScript type-hinting contexts.

Before Fix (Issue Example)

After Fix (Example)

This PR adds a helper function _add_variant_types() to properly include Variant in type completion contexts while excluding it from inheritance contexts where it's invalid.

It is called conditionally within _list_available_types() to ensure Variant is only listed as a type and never as an inheritance option.
Tested and confirmed working in relevant type-hinting scenarios:

Variable Type Declaration: (var my_var: Variant)
Container Element Types: (Array[Variant], Dictionary[String, Variant])
Function Return Types: (func get() -> Variant)

The exclusion logic was also confirmed: Variant does not appear in the autocompletion list following the extends keyword.
I'd appreciate any advice on the changes.

Bugsquad edit: Fixes #109439

dalexeev · 2025-10-21T09:49:02Z

modules/gdscript/gdscript_editor.cpp

 	}
 }

+static void _add_variant_types(HashMap<String, ScriptLanguage::CodeCompletionOption> &r_result) {


To me, this seems like premature splitting. This is a special case, so there's no need to separate this, an inline block inside _list_available_types() would be sufficient. Also, the function name is confusing: types instead of type when this function adds only one Variant type, and not, for example, all built-in Variant types.

That's a very helpful review, thanks! 🙏
It's my first time submitting a PR , so I really appreciate you catching these details.
I agree with you completely; this certainly looks like premature splitting. I'll follow your suggestion and move it back to an inline block within _list_available_types(), as the Variant is probably the only type needed for this change.
I apologize for the types plural—that was an oversight (and a lazy use of auto-complete!).

HolonProduction

I think the analysis of the problem is wrong. It's not that Variant is inherently missing, it's that variant is called Nil in the variant type enum names (I think Variant::NIL is supposed to be GDScripts Variant but if someone more knowledgeable could confirm this it would be great). In completion it appears under that name:

which is obviously wrong.

This PR adds Variant to the list without handling the wrong Nil option.

A fix should happen in _find_build_in_variants which is responsible for adding variant types.

_{Don't be confused by the special case for Nil in _find_build_in_variants which converts it to null. That's an erroneous codepath. This method should not be resposible for adding null. There is other code to handle this.}

AThousandShips · 2025-10-21T10:05:25Z

Please do not request another review without having made any changes, wait until you've resolved the issue that the reviewer has raised

dalexeev · 2025-10-21T10:11:00Z

It's not that Variant is inherently missing, it's that variant is called Nil in the variant type enum names (I think Variant::NIL is supposed to be GDScripts Variant but if someone more knowledgeable could confirm this it would be great).

No, I don't think that's quite right. Nil is a type whose only value is null. GDScript has omitted this type because it's currently rather useless (previously, in one of the older 3.x versions, we even had a documentation page for Nil). Perhaps Nil may become relevant in the future if we add support for nullable or union types, but currently, we don't need it.

It's true that TYPE_NIL, in combination with PROPERTY_USAGE_NIL_IS_VARIANT, is used to denote Variant. Thus, TYPE_NIL can potentially denote three different types: void, Nil, and Variant. But this doesn't mean that TYPE_NIL (and especially Nil) is equivalent to Variant.

HolonProduction · 2025-10-21T10:32:03Z

I guess it's more complicated then 😅, still Nil needs to be filtered out as well since it is currently no GDScript type.

Also the docs for PROPERTY_USAGE_NIL_IS_VARIANT state: "If property has nil as default value, its type will be Variant." I guess this is a bit misleading then and is talking about types not default values?

dalexeev · 2025-10-21T10:50:13Z

Also the docs for PROPERTY_USAGE_NIL_IS_VARIANT state: "If property has nil as default value, its type will be Variant." I guess this is a bit misleading then and is talking about types not default values?

The editor interprets TYPE_NIL without PROPERTY_USAGE_NIL_IS_VARIANT differently. For return types, it will most likely be interpreted as void. For variables, parameters, etc., it can be interpreted as Variant, Nil, and sometimes null.

mu3657 · 2025-11-03T04:40:50Z

I've made another commit which fixed _find_built_in_variants() to properly exclude NIL when exclude_nil=true.
And added Variant directly in_list_available_types()as inline block.May this be a sufficient fix？
ps: I came across a similar issue here: #109439

HolonProduction · 2025-11-03T10:22:14Z

The exclude_nil parameter is unnecessary. Nil should always be excluded, it is never valid in any capacity. The replacement with null makes no sense in the context of this method.

When you look at the usages:

it is used in _list_available_types here exclude nil is always true
it is used in _find_identifiers here exlcude nil is always false
- but what does that do in this context? Well in this context this means that _find_built_in_variants will add null as option.
- directly after that in _find_identifiers keyword options are added. null is part _keywords and will overwrite the option added by _find_built_in_variants. We can safely skip Nil and still get null as option.

Please just always skip Nil and remove the parameter. Otherwise this looks like the correct approach to me.

…autocompletion

mu3657 · 2025-11-03T11:30:59Z

So now the current changes cut the whole exclude_nil from original _find_built_in_variants（） and remove it from the parameter list.
The compilation seems to work fine. Would this one be sufficient？

HolonProduction

LGTM like this. Might be nice to add a test case for it, but I don't see this being very prone to regressions, so it's probably fine.

Repiteo · 2025-11-21T20:52:48Z

Thanks! Congratulations on your first merged contribution! 🎉

mu3657 requested a review from a team as a code owner October 21, 2025 09:29

mu3657 closed this Oct 21, 2025

mu3657 reopened this Oct 21, 2025

AThousandShips added enhancement topic:gdscript topic:editor bug and removed enhancement labels Oct 21, 2025

AThousandShips added this to the 4.6 milestone Oct 21, 2025

dalexeev reviewed Oct 21, 2025

View reviewed changes

HolonProduction requested changes Oct 21, 2025

View reviewed changes

mu3657 requested a review from HolonProduction October 21, 2025 09:54

mu3657 force-pushed the master branch from 30a6b79 to 025143d Compare November 3, 2025 04:16

mu3657 force-pushed the master branch 2 times, most recently from ada9392 to c79eb19 Compare November 3, 2025 10:57

Fix: Add Variant to type autocompletion and filter out Nil option in …

f428358

…autocompletion

mu3657 force-pushed the master branch from c79eb19 to f428358 Compare November 3, 2025 11:10

HolonProduction approved these changes Nov 20, 2025

View reviewed changes

Repiteo merged commit e873576 into godotengine:master Nov 21, 2025
20 checks passed

akien-mga changed the title ~~Fix: Add Variant to type autocompletion~~ Add Variant to type autocompletion Nov 27, 2025

Uh oh!

Conversation

mu3657 commented Oct 21, 2025 • edited by HolonProduction Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dalexeev Oct 21, 2025

Choose a reason for hiding this comment

Uh oh!

mu3657 Oct 21, 2025

Choose a reason for hiding this comment

Uh oh!

HolonProduction left a comment

Choose a reason for hiding this comment

Uh oh!

AThousandShips commented Oct 21, 2025

Uh oh!

dalexeev commented Oct 21, 2025

Uh oh!

HolonProduction commented Oct 21, 2025

Uh oh!

dalexeev commented Oct 21, 2025

Uh oh!

mu3657 commented Nov 3, 2025

Uh oh!

HolonProduction commented Nov 3, 2025

Uh oh!

mu3657 commented Nov 3, 2025

Uh oh!

HolonProduction left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Repiteo commented Nov 21, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

mu3657 commented Oct 21, 2025 •

edited by HolonProduction

Loading