Add an optional untyped_declaration warning

[ryanabx]

Addresses (and may close) godotengine/godot-proposals#173

Adds a new property to ProjectSettings: debug/gdscript/warnings/untyped_declaration, which will print a warning or error if there are variables, parameters, or constants that aren't explicitly typed using : <type> or during initialization, :=.

var foo: int = 0 # Good
var bar := 0 # Also good
var baz = 0 # Warning will be thrown

A warning will also be thrown if a function does not have an explicit return type. This does not affect _init() as it shouldn't have a return type other than void anyways, and is always implicitly void.

func foo() -> int: # Good
    return 0

func bar(): # Warning will be thrown
    return 1

Feel free to test!

Bugsquad edit: Outdated information removed.

[AThousandShips]

(also the failure of the "Test Godot Project" isn't related to this PR but a random error)

[YeldhamDev]

My requests were done, but someone from the GDScript team should do the proper review.

[AThousandShips]

Comment and code style and phrasings look good to me, haven't tested the code specifically

[ryanabx]

Went ahead and tested this with my own project. Everything appears to work as expected! 🥳

EDIT: I need to investigate an issue with lambdas

[ryanabx]

Issue with lambdas is fixed! I think it would now be ready for review!

[anvilfolk]

Don't currently have time for a more thorough review, but since I didn't notice any explicit mention of class members, I assume this already works with them, because their declaration might work as an assignable? :)

[ryanabx]

Don't currently have time for a more thorough review, but since I didn't notice any explicit mention of class members, I assume this already works with them, because their declaration might work as an assignable? :)

Class member variables and functions work!

[AThousandShips]

I'm not sure return values fall under "static typing" and warrants a separate error setting

[MewPurPur]

Our static typing page claims they are. (Also our "automatic static typing" setting adds return types indiscriminately)

[dalexeev]

Resolved

The bug with setter should be fixed this way:

godot/modules/gdscript/gdscript_analyzer.cpp

Line 1280 in 0a7f75e

if (member.variable->getter != nullptr) {

 if (member.variable->getter != nullptr) {
-    member.variable->getter->set_datatype(member.variable->datatype);
+    member.variable->getter->return_type = member.variable->datatype_specifier;
+    member.variable->getter->set_datatype(member.get_datatype());
 
     resolve_function_body(member.variable->getter);
 }
 if (member.variable->setter != nullptr) {
-    resolve_function_signature(member.variable->setter);
-
-    if (member.variable->setter->parameters.size() > 0) {
-        member.variable->setter->parameters[0]->datatype_specifier = member.variable->datatype_specifier;
-        member.variable->setter->parameters[0]->set_datatype(member.get_datatype());
-    }
+    ERR_CONTINUE_MSG(member.variable->setter->parameters.is_empty(), "Parser bug: Setter must have an argument.");
+    member.variable->setter->parameters[0]->datatype_specifier = member.variable->datatype_specifier;
+    member.variable->setter->parameters[0]->set_datatype(member.get_datatype());
 
     resolve_function_body(member.variable->setter);
 }

Also note that you can optionally specify a type for the for loop variable (see #80247). This is a bit different from the rest of the cases, so please don't do anything about it just yet. I will think about it and write my opinion later.

[ryanabx]

@AThousandShips Since this PR is ready and approved, would it be possible to update the milestone to 4.2?

[adamscott]

Discussed during the GDScript Team meeting. Looks good! Thanks for the PR, @ryanabx!

[akien-mga]

Needs a rebase.

[ryanabx]

Needs a rebase.

Done!

[akien-mga]

Thanks!

[sandygk]

I am using 4.2 beta 3 and for some reason I get warnings when I don't specify the -> void return type, but in the PR description it says it's not required.

This does not affect _init() as it shouldn't have a return type other than void anyways, and is always implicitly void.

Did this changed at some point?

[ryanabx]

I am using 4.2 beta 3 and for some reason I get warnings when I don't specify the -> void return type, but in the PR description it says it's not required.

This does not affect _init() as it shouldn't have a return type other than void anyways, and is always implicitly void.

Did this changed at some point?

Init doesn't have a return type, and I think it actually warns you if you do use one, not sure.

For any other method, a warning is issued if there's no return type specified

[dalexeev]

This does not affect _init() as it shouldn't have a return type other than void anyways, and is always implicitly void.

Did this changed at some point?

If I remember correctly, this was originally implemented incorrectly. I've updated the first post.

I don't think we should make an exception for _init() and _static_init(), since explicit void is allowed for them (unlike some other languages) and is generated by autocompletion (if you enabled the text_editor/completion/add_type_hints editor setting). For _ready() you can also specify only void or no type at all, but the warning is generated.

[sandygk]

What I'd suggest is to make -> void optional. So if it's not added, and nothing is returned, the function is void. It keeps the code shorter, cleaner, and requires less typing. The same way we don't do f(void) if there are no arguments, (like we used to do in C). If there are no arguments, we know it by the fact there aren't any, we don't have to explicitly say it. Well, the same applies to the return type. If we don't return anything in the function, then it's void. If we return something, then it isn't. And the compiler can check that.

And autocompletion helps, but only when implementing already defined functions that it can suggest. For new functions it won't know that you want it to be void, so it's unnecessary extra typing if you want your code to be strongly typed.

For instance TypeScript works the way I suggest. In the following code it will complain if I don't type the argument a, but it doesn't complain if the function is not declared as void:

function f(a: string) {
    console.log(a)
}

if we still see value in forcing the developer to explicitly type -> void, then we could at least make it an option to allow implicit void return type

[sandygk]

I added a feature request to Infer implicit void return type in GDScript for functions without return values