[GDScript] Fix type mismatch in optimized single arg range
#68125
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #68093.
When
range
is used in afor
loop and when all of its 1/2/3 arguments are constants (int
orfloat
each) then it's being optimized to generate a loop directly without generating an actual array. In such caselist->reduced_value
of the relevantGDScriptParser::ForNode
should be set toint
/Vector2i
/Vector3i
according to the argument count. The problem was in case of a single argument the argument was not casted toint
, meaning in case the original argument was afloat
thereduced_value
would end up being afloat
as well.This PR solves it by adding the missing cast. I'm casting to
int32_t
to make it consistent with 2/3 arguments cases asVector2i
/Vector3i
used in there are capable of storing only 32-bit signed integers. Making therange
work properly with 64-bit integers (including the optimizedfor
case) is for another PR (I've already done it partially in #67025, without the optimizedfor
part).Note that if
range
is optimized thenfor
's variable is already annotated to be anint
(including the bugged single argument case):godot/modules/gdscript/gdscript_analyzer.cpp
Lines 1408 to 1412 in e675154
so when the actual assigment during looping is happening the conversion should happen even from a
float
. Meaning the inconsistency fixed in this PR was not the solely reason of the bug in #68093. But the no-conversion bug is likely to be the cause of e.g. #62650 which might be fixed by #62674/#62688 so it's not like it will be left unfixed.