Fix: Add Variant to type autocompletion

[mu3657]

Fixes #111854

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]

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.

[mu3657]

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]

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

[dalexeev]

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]

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]

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]

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]

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.

[mu3657]

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？