You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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).
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.
Environment
V 0.5.1 99f141f74(verified no relevant commits land between that and current masterb6dfae560)Problem
A C shim that needs to call libgc directly (e.g.
GC_register_my_thread,GC_get_stack_base) cannot just write:because V's
vlib/gcmodule ships a wrappergc.hthat uses V-only types (u64, etc.) and is not legal standalone C. Including it from a plain.cfile produces a cascade of unknown-type errors.The workaround is to bypass the V wrapper by including the bundled libgc header directly:
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 importsgc):Compilation fails with "use of undeclared identifier
u64" (or similar) because V's wrapper assumes V's prelude.Proposed fix
Either:
vlib/gc's emittedgc.hlegal 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).v_gc.h) and leave the system pathgc.hto resolve to libgc's real header.Downstream evidence
CX's
vcx/cx/gc_thread_shim.chas a comment block explaining the workaround: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.