`$if` assignment will crash compiler

[kbkpbot]

Describe the bug

Assignment with $if will cause compiler panic.

It may related to issue #26053

Reproduction Steps

i.v

module main

fn ret[T](str string) !T {
        val := $if T is i8 {
                T(123)
        } $else {
                T(123)
        }
        return val
}

fn main() {
        x := ret[f32]('1.0')!
        dump(x)
}

Expected Behavior

compile ok

Current Behavior

$ v i.v
================== C compilation error (from tcc): ==============
cc: /tmp/v_1000/i.01KCZH5GMFD7NKFN96P819F6HW.tmp.c:5065: error: expression expected before '#'
=================================================================
Try passing `-g` when compiling, to see a .v file:line information, that correlates more with the C error.
(Alternatively, pass `-show-c-output`, to print the full C error message).
builder error:
==================
C error found. It should never happen, when compiling pure V code.
This is a V compiler bug, please report it using `v bug file.v`,
or goto https://github.com/vlang/v/issues/new/choose .
You can also use #help on Discord: https://discord.gg/vlang .

Possible Solution

fix cgen

Additional Information/Context

No response

V version

V 0.4.12 1cdb0f5

Environment details (OS name and version, etc.)

V full version	V 0.4.12 1cdb0f5
OS	linux, Ubuntu 24.04.3 LTS
Processor	8 cpus, 64bit, little endian, Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
Memory	11.6GB/15.51GB
V executable	/media/HD/github/kbkpbot/v/v
V last modified time	2025-12-21 03:52:13
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/match
Git version	git version 2.43.0
V git status	weekly.2025.46-252-g129ea228
.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 2025-02-13 HEAD@f8bd136d (x86_64 Linux)
tcc git status	thirdparty-linux-amd64 696c1d84
emcc version	N/A
glibc version	ldd (Ubuntu GLIBC 2.39-0ubuntu8.6) 2.39

[kbkpbot]

cgen just generate wrong c code:

VV_LOC _result_f32 main__ret_T_f32(string str) {
        f32 val = #if false
        {
        }
        #else
        {
                ((f32)(123));
        }
        #endif
        ;
        _result_f32 _t2 = {0};
        builtin___result_ok(&(f32[]) { val }, (_result*)(&_t2), sizeof(f32));
        return _t2;
}

[dy-tea]

It appears for some reason node.is_expr is set to false here when it should be true.

[dy-tea]

Call stack of comptime_if at this location:

#0  v__gen__c__Gen_comptime_if (
    _v_toheap_node=<error reading variable: value of type `v__ast__IfExpr' requires 18446744073709551615 bytes, which is more than max-value-size>, g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/comptime.v:387
#1  0x0000000000b00115 in v__gen__c__Gen_expr (
    node_=<error reading variable: value of type `v__ast__Expr' requires 18446744073709551615 bytes, which is more than max-value-size>, g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:3892
#2  0x0000000000a6a44a in v__gen__c__Gen_assign_stmt (
    node_=<error reading variable: value of type `v__ast__AssignStmt' requires 18446744073709551615 bytes, which is more than max-value-size>, g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/assign.v:1089
#3  0x0000000000aecd0e in v__gen__c__Gen_stmt (
    node=<error reading variable: value of type `v__ast__Stmt' requires 18446744073709551615 bytes, which is more than max-value-size>, g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:2627
#4  0x0000000000ae898e in v__gen__c__Gen_stmts_with_tmp_var (
    tmp_var=<error reading variable: value of type `string' requires 18446744073709551615 bytes, which is more than max-value-size>, stmts=..., g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:2304
#5  0x0000000000ae6702 in v__gen__c__Gen_stmts (stmts=..., g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:2139
#6  0x0000000000b9b9d1 in v__gen__c__Gen_gen_fn_decl (skip=0 '\000', node=0x7ffff5bf4d60,
    g=0x7fffe445ea40) at /home/dylan/Repos/v/vlib/v/gen/c/fn.v:540
#7  0x0000000000b94b17 in v__gen__c__Gen_gen_fn_decl (skip=0 '\000', node=0x7ffff5bf4d60,
    g=0x7fffe445ea40) at /home/dylan/Repos/v/vlib/v/gen/c/fn.v:241
#8  0x0000000000b93ff0 in v__gen__c__Gen_fn_decl (
    node=<error reading variable: value of type `v__ast__FnDecl' requires 18446744073709551615 bytes, which is more than max-value-size>, g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/fn.v:152
#9  0x0000000000aec958 in v__gen__c__Gen_stmt (
    node=<error reading variable: value of type `v__ast__Stmt' requires 18446744073709551615 bytes, which is more than max-value-size>, g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:2597
#10 0x0000000000ae898e in v__gen__c__Gen_stmts_with_tmp_var (
    tmp_var=<error reading variable: value of type `string' requires 18446744073709551615 bytes, which is more than max-value-size>, stmts=..., g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:2304
#11 0x0000000000ae6702 in v__gen__c__Gen_stmts (stmts=..., g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:2139
#12 0x0000000000acd568 in v__gen__c__Gen_gen_file (g=0x7fffe445ea40)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:946
#13 0x0000000000acce72 in v__gen__c__cgen_process_one_file_cb (wid=4, idx=79, p=0x3baa0c0)
    at /home/dylan/Repos/v/vlib/v/gen/c/cgen.v:890
#14 0x000000000071e90a in sync__pool__process_in_thread (task_id=4, pool=0x3baa0c0)
    at /home/dylan/Repos/v/vlib/sync/pool/pool.c.v:120
#15 0x0000000000684787 in sync__pool__process_in_thread_thread_wrapper (arg=0x3babf00)
    at /tmp/v_1000/v2.01KDNRY5YE2X7HS1QCD7B059CM.tmp.c:17027
#16 0x00007ffff7ca80d6 in start_thread (arg=<optimized out>) at pthread_create.c:448
#17 0x00007ffff7d3b05c in __clone3 () from /usr/lib/libc.so.6

[kbkpbot]

I remember some solution for such situation is something like this:

VV_LOC _result_f32 main__ret_T_f32(string str) {
        f32 val = 0;
        #if false
        {
        }
        #else
        {
                val = ((f32)(123));
        }
        #endif
        ;
        _result_f32 _t2 = {0};
        builtin___result_ok(&(f32[]) { val }, (_result*)(&_t2), sizeof(f32));
        return _t2;
}

Note that it may need to generate a tmp var before the #if ...