_parse_function_signature takes a single line (line 44 of analyzer/checkers/function-checker.gd), so a declaration wrapped across several lines is read from its first line only. Two checks depend on that parse and both give wrong answers, in opposite directions.
parameters counts what it finds on the first line. A wrapped declaration keeps its initial count of 0, so it never exceeds any limit.
missing_return_type looks for -> on the same first line. On a wrapped declaration the arrow sits on a later line, so a function with a declared return type is reported as missing one.
What that cost us, measured
We ran both checks over 497 files and compared against the real declarations:
| check |
reported |
real |
effect |
parameters |
7 |
145 |
hid 138 real findings |
missing_return_type |
153 |
10 |
invented 143 false findings |
One defect, two opposite consequences. The first makes the linter look clean, the second makes it look noisy, and neither reading points at the parser.
Repro
func wrapped(
a: int,
b: int,
c: int,
d: int,
e: int,
f: int,
g: int,
h: int,
i: int) -> void:
passNine parameters and a declared return type. Reported as 0 parameters and as missing a return type.
Suggested fix
Join the declaration to its closing parenthesis before parsing it, then count parameters and test for -> on the joined text.
Same root as #15 and as the static func case: the declaration is identified from one line of text. A parser that reads to the closing parenthesis would close all three.
Measured against the current main, plugin version 3.3.0.
_parse_function_signaturetakes a singleline(line 44 ofanalyzer/checkers/function-checker.gd), so a declaration wrapped across several lines is read from its first line only. Two checks depend on that parse and both give wrong answers, in opposite directions.parameterscounts what it finds on the first line. A wrapped declaration keeps its initial count of 0, so it never exceeds any limit.missing_return_typelooks for->on the same first line. On a wrapped declaration the arrow sits on a later line, so a function with a declared return type is reported as missing one.What that cost us, measured
We ran both checks over 497 files and compared against the real declarations:
parametersmissing_return_typeOne defect, two opposite consequences. The first makes the linter look clean, the second makes it look noisy, and neither reading points at the parser.
Repro
Nine parameters and a declared return type. Reported as 0 parameters and as missing a return type.
Suggested fix
Join the declaration to its closing parenthesis before parsing it, then count parameters and test for
->on the joined text.Same root as #15 and as the
static funccase: the declaration is identified from one line of text. A parser that reads to the closing parenthesis would close all three.Measured against the current
main, plugin version 3.3.0.