inconsistent type checking for voidptr field in struct initialization vs direct assignment

[v420v]

Describe the bug

The compiler has inconsistent type checking behavior for voidptr fields in structs. When directly assigning a non-pointer value to a voidptr field, the compiler correctly throws an error. However, the same type check is missing during struct initialization, allowing invalid assignments to pass without error.

Reproduction Steps

module main

struct Foo {
	mut:
	bar voidptr
}

fn main() {
	n := 1 // this is typed as int

	mut foo := Foo{}
	//foo.bar = n // error: cannot assign to `foo.bar`: expected `voidptr`, not `int`

	foo2 := Foo{bar: n} // The problem is that this doesn't throw an error

	println('$foo, $foo2') // avoid unused variable warnings
}

Expected Behavior

┌──(ibukiyoshida)-[~/v]-[master]
└─$ v bug.v
bug.v:14:14: error: cannot assign to `bar`: expected `voidptr`, not `int`
   12 |     //foo.bar = n // error: cannot assign to `foo.bar`: expected `voidptr`, not `int`
   13 | 
   14 |     foo2 := Foo{bar: n} // The problem is that this doesn't throw an error
      |                 ~~~~~~
   15 | 
   16 |     println('$foo, $foo2') // avoid unused variable warnings

Current Behavior

================== C compilation error (from cc): ==============
cc: /tmp/v_501/bug.01JR2468S182QFYWSDQ5XYTA3M.tmp.c:5883:39: error: incompatible integer to pointer conversion initializing 'voidptr' (aka 'void *') with an expression of type 'int' [-Wint-conversion]
cc:         main__Foo foo2 = ((main__Foo){.bar = n,});
cc:                                              ^
cc: 1 error generated.
================================================================
(You can pass `-cg`, or `-show-c-output` as well, to print all the C error messages).
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

v/checker/struct.v
add the following code arround line 836

if exp_type_sym.kind == .voidptr && !got_type.is_ptr() && !c.inside_unsafe {
    if !(init_field.expr.is_nil() || got_type == ast.voidptr_type) {
        got_typ_str := c.table.type_to_str(got_type)
            c.error('cannot assign to `${field_name}`: expected `voidptr`, not `${got_typ_str}`', init_field.pos)
    }
}

Additional Information/Context

No response

V version

V 0.4.10 4872e3c

Environment details (OS name and version, etc.)

V full version	V 0.4.10 4872e3c.4872e3c
OS	macos, macOS, 14.0, 23A344
Processor	8 cpus, 64bit, little endian, Apple M1
Memory	0.1GB/8GB
V executable	/Users/ibukiyoshida/v/v
V last modified time	2025-04-05 04:32:48
V home dir	OK, value: /Users/ibukiyoshida/v
VMODULES	OK, value: /Users/ibukiyoshida/.vmodules
VTMP	OK, value: /tmp/v_501
Current working dir	OK, value: /Users/ibukiyoshida/v
Git version	git version 2.39.3 (Apple Git-146)
V git status	weekly.2025.14-9-g4872e3cf-dirty
.git/config present	true
cc version	Apple clang version 15.0.0 (clang-1500.3.9.4)
gcc version	Apple clang version 15.0.0 (clang-1500.3.9.4)
clang version	Apple clang version 15.0.0 (clang-1500.3.9.4)
tcc version	tcc version 0.9.28rc 2024-02-05 HEAD@105d70f7 (AArch64 Darwin)
tcc git status	thirdparty-macos-arm64 e447816c
emcc version	N/A
glibc version	N/A

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-22530

[felipensp]

I've fixed the missing cast to allow the current initialization works on -cstrict, and introduced a notice about asking to cast it to voidptr.