Fix enum autocompletion for core classes

[dcaoc03]

While writing a gdscript, autocompletion wouldn't suggest Enum names for core classes and also wouldn't suggest Enum Values even after the Enum name had been typed. This has now been fixed.

Now, while finding identifiers in a class, enumeration names are also fetched and enumeration constants are now suggested as well.

Fixes #88858.

[akien-mga]

CC @HolonProduction

[HolonProduction]

I can confirm, that the changes solve the issue 👍

Still the location should get set correctly as well. Otherwise we might run into sorting problems.

Besides that it would be nice to have tests to ensure this working. Would be nice if you could add them. (The whole testing system for autocompletion, is quite new and might have some rough edges. So if you don't know how, feel free to ask, or just don't do it and I'll put the issue on my todo list.)

[dcaoc03]

Sure thing! I'll be sure to add the locations and try to do some tests.

[dcaoc03]

@HolonProduction just to be sure I understood the autocompletion test syntax. A very simple test could look like this:

enum_values_autocompletion.gd

extends Control

func _ready():
    AStarGrid2D.Heuristic.➡

enum_values_autocompletion.cfg

[output]
include=[
    {"display": "HEURISTIC_MAX"},
    {"display": "HEURISTIC_OCTILE"},
]

Please feel free to correct me, I'll be sure to fix anything before committing any new changes.

[HolonProduction]

That looks about right. I'd maybe add builtin to the file name, to separate it from GDScript enums which take a different code path.

Also nitpick but in this case it might make sense to also test the location.
For context a situation which might currently fail (without you adding location information):

• You do completion on a type which inherits from control
• The enum names from Control should appear after the stuff from the type which you are completing on, but currently it would appear among them

So see that the location is LOCATION_OTHER when completing on Control. And test that it is LOCATION_OTHER + 1 when completing on a type directly inheriting from Control.

Also I am currently unsure why we have to fallthrough in the ENUM case. It's totally right that you do it, since it aligns with what we did before. I'm just curious why we are doing it.

[dcaoc03]

@HolonProduction sorry to bother again, but I'm not sure on how I should be testing the value of location. In my test, I'm autocompleting a node of type BaseButton (which inherits from Control) and my .cfg looks like this:

[output]
include=[
    {"display": "DrawMode",
     "location": },
    {"display": "Anchor",
     "location": },
]

In this case, the location of DrawMode should be LOCATION_OTHER and the location of Achor should be LOCATION_OTHER + 1, but it seems that I can't directly define "location" as LOCATION_OTHER in the .cfg.

[HolonProduction]

In this case, the location of DrawMode should be LOCATION_OTHER and the location of Achor should be LOCATION_OTHER + 1, but it seems that I can't directly define "location" as LOCATION_OTHER in the .cfg.

From the code LOCATION_OTHER is 1 << 10 or 1024.

Edit: It isn't LOCATION_OTHER but LOCATION_PARENT_MASK, but you seem to have figured that out yourself 👍

[HolonProduction]

Gave it another test and seems to work well with the sorting. Code makes sense as well and the tests seem to pass. LGTM

Still needs approval from the GDScript Core team though

[vnen]

LGTM

[akien-mga]

Thanks! And congrats for your first merged Godot contribution 🎉