vlib/gc wrapper emitted gc.h references V-only types, breaks plain-C shims #28

Environment

• V version: V 0.5.1 99f141f74 (verified no relevant commits land between that and current master b6dfae560)
• OS-agnostic

Problem

A C shim that needs to call libgc directly (e.g. GC_register_my_thread, GC_get_stack_base) cannot just write:

#include "gc.h"

because V's vlib/gc module ships a wrapper gc.h that uses V-only types (u64, etc.) and is not legal standalone C. Including it from a plain .c file produces a cascade of unknown-type errors.

The workaround is to bypass the V wrapper by including the bundled libgc header directly:

#include <gc/gc.h>   /* subdirectory path skips V's gc.h */

This works but is non-obvious and fragile (depends on libgc's own include layout, which has shifted historically).

Reproducer

shim.c (in the context of a V module that imports gc):

#include "gc.h"
int dummy(void) { return 0; }

Compilation fails with "use of undeclared identifier u64" (or similar) because V's wrapper assumes V's prelude.

Proposed fix

Either:

1. Make vlib/gc's emitted gc.h legal standalone C (replace V-only types with the underlying C primitives — u64 → uint64_t, etc., guarded by an #ifdef __V__ so V's cgen still works).
2. Or emit it under a V-specific name (v_gc.h) and leave the system path gc.h to resolve to libgc's real header.

Downstream evidence

CX's vcx/cx/gc_thread_shim.c has a comment block explaining the workaround:

/* Use the subdirectory header to bypass V's `<gc.h>` wrapper
 * (which references V-only types like `u64` and isn't legal C on
 * its own). */
#include <gc/gc.h>

[!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.