v compiler crash when compile generic array code

[kbkpbot]

Describe the bug

v compiler crash when compile generic array code

Reproduction Steps

crash.v

module main

fn decode[T](b []u8) !T {
	$if T is $array {
		val := T{0}
		return decode_array(val)
	}
	return error('error')
}

pub fn decode_array[T](_ []T) []T {
	mut arr := []T{cap : 10}
	v := T(0)
	for _ in 0..10 {
			arr << v
	}
	return arr
}

fn main() {
	x := decode[[]u8]([u8(0),0])!
	dump(x)
}

Expected Behavior

compile ok or report error

Current Behavior

compiler crash:

$ v crash.v
V panic: array.get: index out of range (i,a.len):0, 0
v hash: 50b716b
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:19371: at _v_panic: Backtrace
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:19419: by panic_n2
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:18925: by array_get
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:17399: by v__gen__c__Gen_array_init
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:27770: by v__gen__c__Gen_expr
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:28154: by v__gen__c__Gen_expr
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:20987: by v__gen__c__Gen_assign_stmt
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26582: by v__gen__c__Gen_stmt
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26380: by v__gen__c__Gen_stmts_with_tmp_var
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26228: by v__gen__c__Gen_stmts
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:34110: by v__gen__c__Gen_comptime_if
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:27894: by v__gen__c__Gen_expr
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26609: by v__gen__c__Gen_stmt
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26380: by v__gen__c__Gen_stmts_with_tmp_var
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26228: by v__gen__c__Gen_stmts
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:36876: by v__gen__c__Gen_gen_fn_decl
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:36500: by v__gen__c__Gen_gen_fn_decl
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:36407: by v__gen__c__Gen_fn_decl
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26568: by v__gen__c__Gen_stmt
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26380: by v__gen__c__Gen_stmts_with_tmp_var
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:26228: by v__gen__c__Gen_stmts
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:25079: by v__gen__c__Gen_gen_file
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:25016: by v__gen__c__cgen_process_one_file_cb
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:33136: by sync__pool__process_in_thread
/tmp/v_1000/v2.01JNZ04TMETS8NWZB8CCRK9D1B.tmp.c:15797: by sync__pool__process_in_thread_thread_wrapper

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.4.9 ab2eb00.50b716b

Environment details (OS name and version, etc.)

V full version	V 0.4.9 ab2eb00.50b716b
OS	linux, Ubuntu 24.04.2 LTS
Processor	8 cpus, 64bit, little endian, Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
Memory	4.82GB/15.51GB
V executable	/media/HD/github/kbkpbot/v/v
V last modified time	2025-03-10 03:04:03
V home dir	OK, value: /media/HD/github/kbkpbot/v
VMODULES	OK, value: /home/mars/.vmodules
VTMP	OK, value: /tmp/v_1000
Current working dir	OK, value: /home/mars/v/bug/serial
Git version	git version 2.43.0
V git status	weekly.2025.10-55-g50b716b8-dirty (7 commit(s) behind V master)
.git/config present	true
cc version	cc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
gcc version	gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
clang version	Ubuntu clang version 18.1.3 (1ubuntu1)
tcc version	tcc version 0.9.28rc 2024-07-31 HEAD@1cee0908 (x86_64 Linux)
tcc git status	thirdparty-linux-amd64 0134e9b9-dirty
emcc version	N/A
glibc version	ldd (Ubuntu GLIBC 2.39-0ubuntu8.4) 2.39

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github]

Connected to Huly®: V_0.6-22312

[kbkpbot]

A more simplify version:

module main

fn decode[T]() {
	_ := T{0}
}
fn main() {
	decode[[]u8]()
}

[JalonSolov]

It really doesn't have anything to do with generics.

Your code is trying to access the first element of an empty array, and that is a panic in V.

Perhaps V could have checks added for this type of situation, I don't know if it is something that can be caught at compile time. At least not without a lot of "flow analysis" being added to the compiler.

[jorgeluismireles]

I changed line 5 from val := T{0} to val := T{} and worked.

[spytheman]

It really doesn't have anything to do with generics.

The V compiler itself should not panic for any user code. Note the names in the stack trace - they are from our cgen stage, they are not a runtime error for the user program.

Ideally the V compiler, should either produce V errors, or it should produce a valid program at the end, for any given input source.

[spytheman]

@kbkpbot it usually helps, when reporting compiler panics, if you do first v -g self, so that the stacktrace will have V line numbers in it:

#1 21:20:26 ^ master ~/code/v>./v -g self
V self compiling (-g -o v2)...
V built successfully as executable "v".
#0 21:20:31 ^ master ~/code/v>v z.v
================ V panic ================
   module: builtin
 function: panic_n2()
  message: array.get: index out of range (i,a.len):0, 0
     file: /home/delian/code/v/vlib/builtin/builtin.c.v:188
   v hash: 5439ff9
=========================================
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/builtin/builtin.c.v:88: at panic_debug: Backtrace
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/builtin/builtin.c.v:188: by panic_n2
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/builtin/array.v:474: by array_get
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/array.v:50: by v__gen__c__Gen_array_init
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:3477: by v__gen__c__Gen_expr
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:3848: by v__gen__c__Gen_expr
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/assign.v:542: by v__gen__c__Gen_assign_stmt
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:2417: by v__gen__c__Gen_stmt
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:2192: by v__gen__c__Gen_stmts_with_tmp_var
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:2043: by v__gen__c__Gen_stmts
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/fn.v:509: by v__gen__c__Gen_gen_fn_decl
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/fn.v:222: by v__gen__c__Gen_gen_fn_decl
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/fn.v:139: by v__gen__c__Gen_fn_decl
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:2403: by v__gen__c__Gen_stmt
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:2192: by v__gen__c__Gen_stmts_with_tmp_var
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:2043: by v__gen__c__Gen_stmts
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:906: by v__gen__c__Gen_gen_file
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/v/gen/c/cgen.v:853: by v__gen__c__cgen_process_one_file_cb
/tmp/v_1000/../../../../../../home/delian/code/v/vlib/sync/pool/pool.c.v:118: by sync__pool__process_in_thread
/tmp/v_1000/v2.01JP3ADF716WCEF4JQ6A3WE5BA.tmp.c:15801: by sync__pool__process_in_thread_thread_wrapper
0x7ffff7f53609: by ???
#1 21:20:34 ^ master ~/code/v>

[spytheman]

vlib/v/gen/c/array.v:50 is doing:

        for i, expr in node.exprs {
            if node.expr_types[i] == ast.string_type
...

i.e. looping over one array, while doing array accesses over another; perhaps the 2 fields are just not synchronized for some reason, or the loop has to stop when the end of the shorter one is reached.

[spytheman]

I think it should have been caught earlier, at the checker stage.