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.

[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.