Fix various issues when function argument's default value is array/dictionary

[Xwdit]

In the current version, if the default value of a GDScript function arguments is set to an array or dictionary, it will be null in tooltips and documentation. This PR fixes this issue.

Fix #63018

It also probably fixes some other array and dictionary related issues, but I couldn't find it. Hope someone can test it

[cdemirer]

I can't reproduce the described issue on current master:

func f(x = []):
	pass

func g(x: Array):
	pass

func h(x := [1, 2, 3]):
	pass

The documentation looks fine...
The tooltips: Do you mean while debugging?

[Xwdit]

I can't reproduce the described issue on current master:

func f(x = []):
	pass

func g(x: Array):
	pass

func h(x := [1, 2, 3]):
	pass

The documentation looks fine... The tooltips: Do you mean while debugging?

In fact you have reproduced it. First of all, under normal circumstances, the default value of function parameters in the document should be displayed as void h(x: Array = [1,2,3])

Also, tooltip means that when the project is not running, the script editor should also be able to view the signature of the function by hovering the mouse when calling a function.

The problem is actually because when the default value of the parameter in the function is an array/dictionary, this default value will not be resolved to a constant (it should be a constant) but a variable. But in many places in godot, when getting the default value of a function parameter, it will directly get its precompiled value as a constant, which leads to problems.

However, when the function is actually run at runtime, the default value will be assigned directly to the parameter on the left, so if you look at the value of this parameter at runtime you won't have any problems.

[Xwdit]

I can't reproduce the described issue on current master:

func f(x = []):
	pass

func g(x: Array):
	pass

func h(x := [1, 2, 3]):
	pass

The documentation looks fine... The tooltips: Do you mean while debugging?

In fact you have reproduced it. First of all, under normal circumstances, the default value of function parameters in the document should be displayed as void h(x: Array = [1,2,3])

Also, tooltip means that when the project is not running, the script editor should also be able to view the signature of the function by hovering the mouse when calling a function.

The problem is actually because when the default value of the parameter in the function is an array/dictionary, this default value will not be resolved to a constant (it should be a constant) but a variable. But in many places in godot, when getting the default value of a function parameter, it will directly get its precompiled value as a constant, which leads to problems.

However, when the function is actually run at runtime, the default value will be assigned directly to the parameter on the left, so if you look at the value of this parameter at runtime you won't have any problems.

This issue should be easier to spot after the #62934 merge. The gdscript documentation in the current master does not show any default values ​​for parameters at all

[cdemirer]

Ok I see the issue now, but there is an issue with this fix. It marks the Array/Dictionary parameter nodes as constant (when possible), which triggers a problem since consts are shared:

func fn(x = [1, 2, 3], y = [1, 2, 3]):
	x.append(4)
	y.append(5)
	print(x)
	print(y)

On master:

[1, 2, 3, 4]
[1, 2, 3, 5]

This PR:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]

The existing line result.is_constant = false; just above was probably added to prevent this. A better solution to that would probably be to make a copy when a constant value is assigned to a variable (there are many problems with const stuff right now).

Before that happens, I guess for this issue the editor could display the reduced_value if it exists, without requiring is_constant. Then the is_constant can be set to false safely after folding the Array.

[Xwdit]

Ok I see the issue now, but there is an issue with this fix. It marks the Array/Dictionary parameter nodes as constant (when possible), which triggers a problem since consts are shared:

func fn(x = [1, 2, 3], y = [1, 2, 3]):
	x.append(4)
	y.append(5)
	print(x)
	print(y)

On master:

[1, 2, 3, 4]
[1, 2, 3, 5]

This PR:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]

The existing line result.is_constant = false; just above was probably added to prevent this. A better solution to that would probably be to make a copy when a constant value is assigned to a variable (there are many problems with const stuff right now).

Before that happens, I guess for this issue the editor could display the reduced_value if it exists, without requiring is_constant. Then the is_constant can be set to false safely after folding the Array.

Thanks for your test and suggestion, I have now updated this PR and it should resolve the issue you found

[Xwdit]

Found and fixed some type judgment issues, now everything should works fine.

[Xwdit]

Found and fixed some type judgment issues, now everything should works fine.

Now also fixed for script editor tooltips.

[akien-mga]

Needs rebase to fix CI due to a temporary godot-cpp issue.

[Xwdit]

Needs rebase to fix CI due to a temporary godot-cpp issue.

Rebased to fix CI issue

[akien-mga]

Needs a rebase after other GDScript changes. I checked and the issue is still reproducible, so the changes here are likely still needed. Not critical for 4.0 since we're at RC stage and it's a minor issue, but would be good to review/merge for 4.1 (and then we could cherrypick it for 4.0.x).

[adamscott]

Will push the milestone to 4.2. The GDScript team did not review the PR, but I think it would be nice to in the next weeks, after the 4.1 release.
If the PR is not rebased since then, the team will do itself.

[dalexeev]

This is not a critical bug and a fairly complex problem. It might be better to refactor expression reduction and remove make_*_reduced_value() and update_*_type() rather than adding new methods.

[dalexeev]

Since #63018 resolved by #88211 and #89738, there is no need to work on this PR at this time. However, in the future we may try to refactor expression reduction (see #66218), so I marked this as salvageable.