Scripts fail to load with a parse error on exported projects if it uses editor classes

[ydeltastar]

Tested versions

v4.3.dev.custom_build [2042420]

System information

Windows 11

Issue description

Tool scripts using an editor class such as EditorInterface will fail to load with a parse error only on exported projects.

@tool
extends Node3D

func _init() -> void:
	if Engine.is_editor_hint():
		var editor_filesystem = EditorInterface.get_resource_filesystem()
		if not editor_filesystem.resources_reimported.is_connected(_on_resource_reimport):
			editor_filesystem.resources_reimported.connect(_on_resource_reimport)

func _on_resource_reimport(resources:PackedStringArray):
	pass

Output of debug template console wrapper:

SCRIPT ERROR: Parse Error: Identifier "EditorInterface" not declared in the current scope.
          at: GDScript::reload (res://node_3d.gd:6)
ERROR: Failed to load script "res://node_3d.gd" with error "Parse error".
   at: ResourceFormatLoaderGDScript::load (modules\gdscript\gdscript.cpp:2894)

Well, it makes sense. Editor classes aren't included in distribution builds but there is no conditional compiling in GDScript so tool scripts with game and editor code can't be used at all in a project.

Workarounds:

• Reject types, return to dynamic: var editor_interface = Engine.get_singleton("EditorInterface").
• Distribute the source project with godot.exe.

Steps to reproduce

Export a project that uses the script above with a debug template and run the .console.exe version.

Minimal reproduction project (MRP)

N/A

[AThousandShips]

Related:

• Add conditional compilation directives to GDScript godot-proposals#7375
• GDScript → Add conditional compilation directives godot-proposals#4023

[KoBeWi]

Reject types, return to dynamic: var editor_interface = Engine.get_singleton("EditorInterface").

IMO this is the way. You can do this indirectly for partial safety:

func _ready():
	if Engine.is_editor_hint():
		var editor = load("res://some_script_using_editor_interface.gd")
		editor.connect_reimported(_on_resource_reimport)

where the loaded script does what you quoted above. It can provide a type-safe interface with only the script in the scene doing unsafe calls.

[dalexeev]

It can provide a type-safe interface with only the script in the scene doing unsafe calls.

This will not work with static typing, only with dynamic typing (if you use Engine.get_singleton() and so on for all editor classes).

As a workaround, I would suggest my plugin gdscript-preprocessor (sorry for the self-promotion).

We could try to solve this out of the box by adding an exception for editor classes when analyzing/compiling the script. However, at runtime this should still give an error if execution reaches this point. So I think that this is a rather complex solution, which also adds inconsistency.

[KoBeWi]

This will not work with static typing, only with dynamic typing (if you use Engine.get_singleton() and so on for all editor classes).

No I mean this (for some_script_using_editor_interface.gd from my example):

func connect_reimported(callback: Callable):
	var editor_filesystem := EditorInterface.get_resource_filesystem()
	if not editor_filesystem.resources_reimported.is_connected(callback):
		editor_filesystem.resources_reimported.connect(callback)

This code is type-safe, but it won't cause problems, because it's loaded using load(). The parent script does a dynamic call on this method. Hence I said "partially safe".

[ydeltastar]

Also, this isn't mentioned in the documentation and works when running from the editor leaving it to be discovery possible late in development only after exporting.

[KoBeWi]

Also related: #56798 (I just remembered)

[ydeltastar]

Related: #86013

[lucassene]

Got this happening with me on exported games on 4.3.

The first workaround suggested by @ydeltastar , worked so far.

[TokisanGames]

Just discovered this. I have tool scripts in my game that do stuff in the editor, and already filter their actions based on the editor hint. We made EditorInterface static #75694 to make tool scripts easier. But to break an exported game because a script mentions, but doesn't use the class isn't good.

What about replacing editor classes with dummy classes?

How about recognizing a code block that starts with if Engine.is_editor_hint(): and not including it in the export?

What about giving us preprocessor defines that demark editor only code, to replace if Engine.is_editor_hint() entirely?

[ydeltastar]

Taking Python as an example, the following will execute without errors when evaluating to false even if EditorInterface doesn't exist.

print("Input anything besides 'editor' to succeeded")
x = input()

if "editor" in x:
    print(EditorInterface.get_stuff())
else:
    print("it works")

Python probably replaces it with a placeholder or an error opcode. No need for workarounds on the user side if the parser step is less strict during compilation.

[dalexeev]

Python probably replaces it with a placeholder or an error opcode.

Python is a purely dynamic language, type hints are completely optional. Therefore, any non-existent identifiers do not cause a runtime error until execution reaches them.

GDScript combines the qualities of both dynamic and static typing. GDScript uses type hints and implicitly inferred types for static analysis and optimizations, and reports non-existent identifiers (but this does not apply to attribute/index access). Changing this behavior may be undesirable because it helps users find errors faster.

You can use Engine.get_singleton(&"EditorInterface") instead of EditorInterface, as documented in the description of the new @export_tool_button annotation. Similar techniques can be used for other cases besides accessing editor singletons.

But I agree that this is a pretty important point that can hinder users who want to have different code for different platforms, operating systems, distribution stores and other types of engine builds and custom feature tags. I think there are the following options to solve this problem:

1. Introduce a conditional compilation system in the form of preprocessor directives or another mechanism. This is quite complicated, but could potentially be useful for other scenarios.
2. Change the analyzer and compiler behavior only on export and in the exported project. Instead of a compile-time error, generate a "get global" opcode.
3. Replace the error about a non-existent identifier with a warning, which is treated as an error by default (for compatibility). I think this option is most consistent with the principles of GDScript.

[aekobear]

This bug is hard to uncover with inherited classes. Take this example:

@tool
extends Node
class_name BaseTool

func editor_selection():
  EditorInterface.get_selection()

@tool
extends BaseTool
class_name CustomTool

func _ready():
  print("CustomTool is working!");

If you create a scene with a single CustomTool node, it works perfectly in the editor. But when you export, you get the error:

SCRIPT ERROR: Parse Error: Could not resolve class "BaseTool".
          at: GDScript::reload (res://custom-tool.gd:0)
ERROR: Failed to load script "res://custom-tool.gd" with error "Parse error".
   at: load (modules/gdscript/gdscript.cpp:2775)

There's no mention of EditorInterface at all. Combined with the fact that this functionality only happens on export and is entirely undocumented, basically the only way to uncover the problem is to comment out lines of code one at a time until the problem goes away.