Some usages of `class_name` can produce cyclic errors unexpectedly

---

Bugsquad edit: This issue has been confirmed several times already. No need to confirm it further.

---

Windows 10 64-bit - Godot 3.1 alpha

Edit - Refined issue to focus on cyclic errors.

Certain uses of class_name can produce cyclic errors in situations where there are no cyclic references, and in fact sometimes no other references outside of the single one given.

I've noticed this most frequently in tool script when using is to make a class comparison, but it seems to happen at times in normal script situations.

Recreating it in a sample project has eluded me.

[PetePete1984]

It'll work if you give the base script a class_name and use that in the extends line.
I'm also getting the error when using file names at first (https://github.com/godotengine/godot/blob/master/modules/gdscript/gdscript_parser.cpp#L4947), but it also disappears and doesn't come back after it worked once (as in, after I use the mentioned workaround)

@PetePete1984 Cool, thanks Pete. This is how it is intended to be used then?

While double checking and testing this, I was looking at the get_class() method, and wondering if it should return Node2D? The is CustomClass part is returning true, but is_class("CustomClass") on the other hand is false.

[akien-mga]

CC @reduz @vnen @willnationsdev

[PetePete1984]

I wouldn't say it's intended behaviour, especially not with an error message that implies cyclic inclusions where there aren't any.
get_class() and is_class() are confusing to me in general, can't comment on that really. The source might solve that mystery in the long run, but so far is has been enough for me.

@vnen Would this be something that is in need of a clearer error message?

@PetePete1984 Yes, is has been an amazing thing now in 3.1. Though I did come across a situation where I would've liked to use the new match like match custom_thing.get_class() and compare against several strings. But nothing critical, just a readability and less typing thing.

[willnationsdev]

@avencherus You might be able to get away with:

match custom_thing.get_script():
    <typename>: stuff # script classes
    <typename>: stuff
    _: match custom_thing.get_class():
        "Node": stuff # engine classes

[vnen]

I'm not sure why it's giving this error, I'll have to investigate.

@willnationsdev Not entirely sure what the check for from get_script() part, for me at least, it returns a GDScript object [GDScript:1057].

@vnen Thanks vnen. X) Some other weird things seem to be going on when I went back to try out these suggestions to see if I could give you some better information. I'm going to pull and rebuild and fiddle with it in a little bit. See if there is anything else about it to add. I may have bumped into a different issue as well along the way.

[willnationsdev]

@avencherus the "class names" of script classes are global variables that reference the script. So...

class_name CustomType
match get_script():
    CustomType:
        print("I am a CustomType!") # should print

@willnationsdev Oh neat, I see now. I wasn't expecting class_name to work like that, or the custom type to be available to the match pattern . Thanks for sharing this tip Will.

@vnen Yes, some additional wrinkles to the story. Let me see how well I can articulate them.

Firstly, Pete's solution works, when a base class is given a class_name all appears fine. What I did notice is that going back to the base class and pulling out the class_name CustomBase that I added, it half works. It no longer appears in the node list when adding nodes, but is will work, and no strange errors.

Then to confirm this, I went to recreate the steps of creating a base2.gd -> custom2.gd extended script. Then inside custom.gd use class_name CustomClass2, but no class naming in the base class.

Another issue appeared. The node list had the first one, but listed with an icon that said "Error"

So I modified the first base class so they both used class_name. But got odd results again.

Not everything is showing up in the node list, and then the is keyword only returned true for one of them. Though in this screenshot you can see the node list recognizes CustomClass2, yet in the code behind it, is CustomClass2 is returning false.

It seems like lot of things are getting switched up or are lingering about behind the scenes. Hard to quite predict what it may be doing with my limited knowledge.

Hope that helps. X)

[bfishman]

edit disregard this comment. I hadn't realized that class_name is not implemented in 3.0.6, this issue refers to a 3,1 build anyway.

class_name seems to be broken in 3.0.6. I will make a separate issue, but: