t02_argument_passing fails to compile with gcc 14

[alaviss]

Example

./koch.py tests r tests/lang/s02_core/s02_procedures/t02_argument_passing.nim

Actual Output

FAIL: tests/lang/s02_core/s02_procedures/t02_argument_passing.nim c ( 0.21 sec)
Test "tests/lang/s02_core/s02_procedures/t02_argument_passing.nim" in category "lang"
Failure: reNimcCrash
debugInfo:  compiler exit code was 1 but no Error's were found.
$ bin/nim c --hints:on -d:testing --clearNimblePath --nimblePath:build/deps/pkgs   --nimCache:nimcache/tests/lang/s02_core/s02_procedures/t02_argument_passing.nim_4a8a08f09d37b73795649038408b5f33  tests/lang/s02_core/s02_procedures/t02_argument_passing.nim
t02_argument_passing.nim(353, 34) Hint: Implicit conversion: Receiver 'Base' will not receive fields of sub-type 'Derived' [ImplicitObjConv]
nimcache/tests/lang/s02_core/s02_procedures/t02_argument_passing.nim_4a8a08f09d37b73795649038408b5f33/@mt02_argument_passing.nim.c: In function ‘NimMainModule’:
nimcache/tests/lang/s02_core/s02_procedures/t02_argument_passing.nim_4a8a08f09d37b73795649038408b5f33/@mt02_argument_passing.nim.c:1417:29: error: assignment to ‘_Bool *’ from incompatible pointer type ‘const NI *’ {aka ‘const long int *’} [-Wincompatible-pointer-types]
 1417 |                 _148.Field0 = TM__OnBaGR0NgqkQD11qsebNiQ_107; _148.Field1 = 3;
      |                             ^
execution of an external program 'gcc -c  -w -fmax-errors=3   -Inimskull/lib -Inimskull/tests/lang/s02_core/s02_procedures -o nimskull/nimcache/tests/lang/s02_core/s02_procedures/t02_argument_passing.nim_4a8a08f09d37b73795649038408b5f33/@mt02_argument_passing.nim.c.o nimskull/nimcache/tests/lang/s02_core/s02_procedures/t02_argument_passing.nim_4a8a08f09d37b73795649038408b5f33/@mt02_argument_passing.nim.c' failed with exit code '1'

[zerbina]

The culprit in this case is the call in line 246, with the reduced reproducer being:

proc impl(x: varargs[int], y: varags[bool]) = ...

impl(1 2, false)

sigmatch turns this call into impl([1, 2, 0], [1, 2, 0]), which is wrong, and later leads to bogus code being generated (all backends are affected).

Eventually, #1207 will fix this, but an intermediate quick-fix might also be possible. If nothing else, the call could be moved to a separate knownIssue test.