GDScript 2.0: "Parser bug (please report): Trying to check compatibility of unset value type" error

[TotCac]

Godot version:
current master 4.0 a511a26

OS/device including version:
Windows 10

Issue description:
E 0:00:00:0827 is_type_compatible: Parser bug (please report): Trying to check compatibility of unset value type
<C++ Error> Condition "!p_source.is_set()" is true. Returning: true
<C++ Source> modules/gdscript/gdscript_analyzer.cpp:3157 @ is_type_compatible()

Steps to reproduce:
I don't know because debugger don't show me where it is in my code.
Empty project don't do that

Minimal reproduction project:
n/a

[Calinou]

@TotCac Please upload a minimal reproduction project to make this easier to troubleshoot.

We absolutely need a minimal reproduction project here. Also, please specify the commit hash of your 4.0 build as "latest master" is a moving target.

[TotCac]

build a511a26

I can't upload my whole project. How can I get more information on the context?

[Calinou]

How can I get more information on the context?

I'm not sure if you can do much more. Maybe setting a breakpoint in the C++ source could help, but I'm not sure.

cc @vnen

[Calinou]

I'll close this issue as no minimal reproduction project was provided in time. This issue can be reopened if someone uploads a minimal reproduction project.

[TotCac]

I really don't understand why you close it while in code, where the error pop, there is comment like this:
// TODO: Add safe/unsafe return variable (for variant cases)

and

// These return "true" so it doesn't affect users negatively. ERR_FAIL_COND_V_MSG(!p_target.is_set(), true, "Parser bug (please report): Trying to check compatibility of unset target type"); ERR_FAIL_COND_V_MSG(!p_source.is_set(), true, "Parser bug (please report): Trying to check compatibility of unset value type");

[Calinou]

I really don't understand why you close it while in code, where the error pop, there is comment like this:

We need a minimal reproduction project to be able to diagnose this, unless @vnen is already aware of a solution to this issue somehow.

[TotCac]

After days (weeks) of investigating, I find where does error come from.

On 3.2 i use to define a method like this

func set_object(_object: Object = null) -> void:
if _object:
selected_object = _object
selected_object.map_status = "FLYING"`
(...)

On 4.0 i have the error shown in title
If I remove null assignation as default value for parameter obect, the error is gone

func set_object(_object: Object) -> void:
if _object:
selected_object = _object
selected_object.map_status = "FLYING"`
(...)

I have no idea if the issus should be close of not.

[TotCac]

If I declare

func get_oxygenflow_direction() -> int:
var tot = 0
for dir in oxygen_flow_direction.values():
tot += dir
return tot

The error pop too

When I use

func get_oxygenflow_direction() -> int:
var tot: int = 0
for dir in oxygen_flow_direction.values():
tot += dir
return tot

Maybe it has something to do with static typing and initialization

[Gastronok]

Here's a reasonably minimal project that gets this error on Godot v4.0.dev.calinou.de83ee57e

I'm not really sure what's causing it so I'm just following up with a Please Report. If you run the project and click on it in the error line, it'll point to the line in my project which claims is the source of the problem.

ParserBug.zip

[Hannyson]

I got the same error when I try to create a Thread, it crash when I launch a start()
In the long list of errors in teh debug, I also get this:
E 0:00:01:0543 _ready: Cannot get class 'Thread'.
<Erreur C++> Condition "!ti" is true. Returning: nullptr

core/object/class_db.cpp:529 @ instantiate() Camera.gd:140 @ _ready() E 0:00:01:0543 _ready: Class type: 'Thread' is not instantiable. Condition "!o" is true. Returning: Variant() modules/gdscript/gdscript.cpp:76 @ _new() Camera.gd:140 @ _ready()

[akien-mga]

@Calinou I think @Hannyson's bug was a duplicate of #50831 and not this bug, isn't it? And if so it's fixed already.

[Calinou]

@Calinou I think @Hannyson's bug was a duplicate of #50831 and not this bug, isn't it? And if so it's fixed already.

Maybe, I don't know for certain.

[lyuma]

This issue report is a bit messy, but @Gastronok's repro project works and I can reproduce the parser bug on 85186bc

ERROR: Parser bug (please report): Trying to check compatibility of unset value type

(even if I add a 0 argument to get_used_cells to fix the script error)

Note that another bug exists with this error: #50313 - I also see this error all the time in my own projects, so it's not super hard to reproduce given complex GDScript.

[Chaosus]

The error caused by var event_string : String = player_identifier + suffix line of Player.gd of the @Gastronok project.

[Chaosus]

The simple reproduction script will be:

extends Node3D

func _ready():
	var p : PackedStringArray
	for b in p:
		var t : String = b

[cassandrus]

Hello! I'm not 100% sure that source of this issue is the same, but here it is:

I've made mini-project for you:
game-client_test.zip

Error is in file PlayerAttrs.gd. Error is somehow linked to use of both enum type hint and singleton (I think).
If you omit type hint, it works.
Project uses latest 4.0.alpha12

Hope this helps!

[flotos]

For me this issue is partly resolved by renaming the unparsable class as mentionned in this (duplicate?) ticket : #63439

But only partly because I then get the error on other classes

Update: Doing a git stash -> restart godot -> git stash pop -> restart godot solved the issue for me.

[rblopes]

Just discovered that issue recently, porting one of my old projects to Godot 4 (beta 1).

Doing my own tests, I've found that the following code:

extends Node2D

var some_var: int = some_func()

func some_func() -> int:
	return 42

Reports the following on the console:

  modules/gdscript/gdscript_analyzer.cpp:656 - Parser bug (please report): tried to assign unset node without an identifier.
  Parser bug (please report): Trying to check compatibility of unset value type
  modules/gdscript/gdscript_analyzer.cpp:656 - Parser bug (please report): tried to assign unset node without an identifier.
  Parser bug (please report): Trying to check compatibility of unset value type
  modules/gdscript/gdscript_analyzer.cpp:656 - Parser bug (please report): tried to assign unset node without an identifier.
  Parser bug (please report): Trying to check compatibility of unset value type

However, if I declare the variable after the function, no errors are reported.

I've tried a few combinations, declaring the function as static, annotating the variable as @onready or @export, with the same result: errors reported only if the variable appears first in the code.

I hope that helps a little.

[resinten]

I see this issues exactly as described by @rblopes in 4.0-beta2

@onready var loaded_save: Dictionary = __default_save()

func __default_save() -> Dictionary:
    return {}

causes the problem. Related, it gives me an error if I attempt type inference on the var as @onready var loaded_save := __default_save() although the function in question is explicitly annotated with the return type.

Parse Error: Cannot infer the type of "loaded_save" variable because the initial value doesn't have a set type.

In the meantime, my workaround is to set manually in _ready()

var loaded_save := {}

func _ready():
    loaded_save = __default_save()

func __default_save() -> Dictionary:
    return {}

[koodikulma-fi]

Here is one very simple minimal reproduction code (for Godot 4.0.beta4) - the effects are near immediate (don't even need to save, just comment/uncomment the lines).

So in words, one way to trigger the error is by 1. declaring a class member 2. after declaring a function that uses 3. the member as a default value for an argument 4. with typing. It's okay to use it inside the function though (just not for the arguments), and it's also okay if you don't use type for the argument. Note also that you'll get the error for any scripts open in the script editor, and accordingly if you open Godot with such scripts left open in the editor, you'll be welcomed with some red lines on start up.

Not knowing how it works, but.. Conceptually speaking, if the problem is unset value type, one solution could be to add an extra "run" to the parser, where it collects any default argument refs and fetches the type from them (= sets the value type) - before going on to parsing the arguments further. Or more brutely, doing that run in any case for all the class members (before parsing function arguments).

UPDATE (beta6): The above situation still throws an error in Godot v4.0.beta6, but now the message is:
Could not infer the type of the variable "problem_if_after" because the initial value is "null".

[dalexeev]

Please check if this is reproducible in master. Maybe #67714 fixed that too.

[koodikulma-fi]

Tested that at least the issue reported in the above screenshot still exists in Godot 4.0.beta5. (The error seems to be triggered just like in beta4.)
UPDATE: Oops, thought you meant the new beta5, sorry. (Probably #67714 fixes it.)

[lufog]

From what I have tested:

Fixed in master

#44375 (comment) is fixed in the master.
Test project: parser-bug-test.zip

In v4.0.beta5.official [89a33d2]:

SCRIPT ERROR: Parse Error: Could not preload resource file "res://something.gd".

In v4.0.beta.custom_build [c2f0353]:
No errors

Not fixed in master

#44375 (comment) is not fixed in the master.

In v4.0.beta5.official [89a33d2]:

SCRIPT ERROR: Parse Error: Could not parse singleton "GameSettings" from "res://globals/GameSettings.tscn".
ERROR: Parser bug (please report): Trying to check compatibility of unset target type

v4.0.beta.custom_build [c2f0353]:

SCRIPT ERROR: Parse Error: Could not parse singleton "GameSettings" from "res://globals/GameSettings.tscn".
ERROR: Parser bug (please report): Trying to check compatibility of unset target type

---

#44375 (comment) is not fixed in the master.

In v4.0.beta5.official [89a33d2]:

ERROR: Parser bug (please report): tried to assign unset node without an identifier.
ERROR: Parser bug (please report): Trying to check compatibility of unset value type

v4.0.beta.custom_build [c2f0353]:

ERROR: Parser bug (please report): tried to assign unset node without an identifier.
ERROR: Parser bug (please report): Trying to check compatibility of unset value type

---

#44375 (comment) is not fixed in the master.
Test project: init-order-test.zip

v4.0.beta5.official [89a33d2]:

ERROR: Parser bug (please report): Trying to check compatibility of unset value type

v4.0.beta.custom_build [c2f0353]:

ERROR: Parser bug (please report): Trying to check compatibility of unset value type

[lostminds]

I think this might be related to cyclic class references. Before beta6 this didn't compile at all, but after the improvement/fix in 4.0.beta6 ( #67714 ) you can now have these references. Or, at least the game compiles and runs, but I still get this error (same as above) if I set up a simple cyclic class reference.

E 0:00:00:0697   is_type_compatible: Parser bug (please report): Trying to check compatibility of unset value type
  <C++ Error>    Condition "!p_source.is_set()" is true. Returning: true
  <C++ Source>   modules/gdscript/gdscript_analyzer.cpp:4141 @ is_type_compatible()

The cyclic class reference I tested was a simple one: One node of the class GameBoard has a number of child nodes of the class BoardObject, both classes inherit from Node3D. If I in the script for BoardObject reference the class GameBoard I get the error above when I run the game. If I remove the reference to GameBoard in BoardObject the error goes away.

[cassandrus]

Guys, I'm afraid my issue variant was never resolved and still valid even in RC5. I mean this comment.

I had a similar issue with "match" syntax and it was fixed in #63535, but this one still fails (despite the same set of singletons in both my MRPs).

[akien-mga]

@cassandrus I tested your project, you need to make the script GameSettings.gd the singleton, not the PackedScene GameSettings.tscn.

[cassandrus]

@cassandrus I tested your project, you need to make the script GameSettings.gd the singleton, not the PackedScene GameSettings.tscn.

I think it will do the trick, but why? Is this incorrect usage or just a workaround? Docs page states "You can create an AutoLoad to load a scene or a script that inherits from Node" and "Note that autoload objects (scripts and/or scenes) are accessed just like any other node in the scene tree". Is it incorrect? No more correct?

[akien-mga]

I think it's correct, but maybe not in the context of accessing an enum from that script as type hint. This would warrant a dedicated issue.

[vnen]

You can use a scene or script for autoload but GDScript will not look into an autoloaded scene to check its contents, so for GDScript it is only a regular Node. Not to say this can't be improved, but it is a different problem.