GDScript: Out of order member resolution

[rune-scape]

Implements out of order member resolution
-- this was allowed in some specific places, but this PR pulls it out into its own function to make the behavior consistent
-- and allow more complex ordering

class members are now resolved just before they are needed
-- This means class members will always have resolved types before used, else an error is pushed
same goes for members of external classes
-- This fixes alot of dependency errors.

also fixes a few minor bugs:
-- singleton datatypes now get properly resolved in extends
-- Object and Variant no longer allow array syntax (Variant[int] doesn't parse)
-- pushes an error if a native enum doesn't exist when resolving a type
those were all just missing a line or 2

fixes #68069
fixes #69479
fixes #67085
fixes #69763
fixes #68017
may fix #44375 (didn't read the all the comments, but it addresses the problem in the most recent ones)

[MewPurPur]

Does this address #61159?

[rune-scape]

@MewPurPur i can check in a bit, but my instinct is no

[adamscott]

As is, this PR fixes #69479. I just tested it.
@rune-scape Can you add it in the description?

[rune-scape]

i was annoyed that Variant and Object were the only ones to return a good result early
removing this actually fixes an annoying bug that allows the type Variant[int] but chops off the [int] part in the analyzer. same with Object

[anvilfolk]

Yeah, deleted my comment after realizing that you can probably still fill out some stuff later, so you can do all these checks and assign partial information to result :)

[rune-scape]

:)

[anvilfolk]

You can now let CLASS fallthrough to ENUM since the code is the same! Wonder if there's any other places where this could be done :)

[rune-scape]

@anvilfolk and @adamscott thank you for reviewing!

[rune-scape]

Technically this could be expanded to allow the analyzer to resolve individual members of other scripts, allowing member dependencies both ways between script interfaces, but i'm not sure anyone has a use for that 🙂

[anvilfolk]

Technically this could be expanded to allow the analyzer to resolve individual members of other scripts, allowing member dependencies both ways between script interfaces, but i'm not sure anyone has a use for that 🙂

Wouldn't this actually be really neat now that cyclic dependencies are possible? Could probably come up with a small interesting case like:

# A.gd

var a := B.b_func()

static func a_func() -> int:
  return 42


# B.gd

static func b_func() -> int:
  return A.a_func()

Something like that?

[rune-scape]

@anvilfolk exactly! i do kinda wanna see how difficult it is, so i'll put it on my todo list 😄
who knows, maybe its dead simple

[rune-scape]

i added braces inside resolve_class_member() to make the diff much more readable

[rune-scape]

@MewPurPur no, this doesn't fix #61159, but i found the bug.
#69518 fixes that

[adamscott]

I cannot NOT underline the great teamwork between you both, @rune-scape and @anvilfolk. <3

[rune-scape]

ok, it took a while to figure out, but tests are added and they helped me find a few bugs! they're finally done

[anvilfolk]

Nice! Look forward to seeing this merged so I can fix conflicts with the enum PR! :)

[akien-mga]

Great work!

[akien-mga]

Thanks!

[lufog]

I think this PR broke something in Autoloads.

on ec4de82:
MRP works

on 6debf86:
I get Parser Error: Cannot find member "audio_player" in base "".

MRP: var_from_autoload_test.zip

[adamscott]

@lufog Can you create an issue?

[lufog]

@adamscott, to be honest, I don't even know how to properly formulate it. But I'll try.

[rune-scape]

@lufog thank you for the project! i think i found the mistake

[adamscott]

I don't even know how to properly formulate it.

@lufog You can formulate it like "Autoloads broken: cannot find members" and copy/paste what you wrote here in the issue.

It will be easier for @rune-scape to create a PR that links to your issue.

[lufog]

Done #70127

[dmaz]

since this pr I'm also having some errors some of which was just lazy code on my part. My biggest issue that I'm having trouble isolating is from an autoload that loads a bunch of resources that create instances from a named base class. I get this
Parser Error: Could not resolve class ItemBase
I'm working on getting an example to actually give the same error

one of the other issues that was easily fixed was a reference from an autoload to another autoload
play3D(null, Game.player.global_position, key, 1.0, parms)
clearly this is lazy but it worked and being a "simple" scripting language I would figure we still want the compiler to be able be ok with stuff like this

[adamscott]

@dmaz Please create issues and link them to this PR. Commenting here doesn't really help fixing your issues.

[dmaz]

yeah for sure... just haven't been able to isolate class one into an example yet