v3: untyped nil passed to a pointer-to-handle parameter becomes a non-null pointer #29306

Describe the bug

Passing unsafe { nil } to &Handle, where Handle aliases voidptr, generates a non-null pointer to a null handle rather than a null output pointer. The callee observes the wrong pointer value.

Reproduction Steps

Save as repro.v:

type Handle = voidptr

fn is_null_output(output &Handle) bool {
    return output == unsafe { nil }
}

fn main() {
    assert is_null_output(unsafe { nil })
}

v -new-compiler -cc tcc -o repro repro.v
./repro

Also reproduces with -cc gcc.

Expected Behavior

The assertion passes: the output pointer itself is null.

Current Behavior

The assertion fails and the binary exits 1. Relevant generated C:

bool is_null_output(void** output) {
    return output == NULL;
}
// Call site:
is_null_output(&((void*[]){NULL})[0])

The temporary array's address is non-null.

Workaround and Impact

An explicitly typed null local passes with both TCC and GCC:

output := unsafe { &Handle(nil) }
assert is_null_output(output)

This affected a count-only vkEnumeratePhysicalDevices query: the non-null output pointer changes it into a zero-capacity output-buffer query, leaving the player with no discovered devices. The public antono2/v_vulkan_video caller workaround restores Lavapipe discovery. This minimal reproducer needs no Vulkan or other dependencies.

V version and Environment

V 0.5.2, upstream commit 0dc6a692ed5333cbe3f05ff63ae0766f0333038a (current master when retested), clean source-built checkout. Ubuntu 24.04 x86-64. Reproduces with strict -new-compiler using both bundled TinyCC and GCC 13.3.0. Released V 0.5.2 (7647ce1) with TinyCC passes.